Ability to remember last Mopidy state without proper shutdown?

[kokosowy]

Hi!

Thanks for this neat extension, it works great. This is a request and question whether you could develop kind of "autosave" slots for Mopidy status running in some time intervals, so status could be resumed in case of sudden power outage / hard reset? It'd be handy for devices basing on raspberry pi that has no or limited number of controls, where it's easier to cut the power to turn off the radio than making and using mechanism of proper shutting down.

Please let me know what you think. Thanks.
K

[sphh]

Glad that you like it!

I like that idea. (I just wonder, what the file system on your SD thinks about this shutdown method?)

Should the state be saved in set intervals or whenever the tracklist or the track played changes? Or even the mute/volume level?

[kokosowy]

Hi @sphh,

Thanks for your reply, sorry it took me a while to respond. SD has ext4 on it. I know this is not best practice just to power device down , but reality sometimes is different than best practices especially like this kind of single-purpose devices.

I think it'd be great to save state just after any action like playlist manipulation, changing track, controls like pause/stop/play/repeat/shuffle and volume changes as well.

Does it still sound interesting?

[sphh]

I already thought, you have lost interest!

That would also be my preferred solution, if … well, if there were not the issue with excessive tear and wear on the SD card. It should be better for USB-sticks, so it must definitely be optional!

Do you want to have a go and make a pull request yourself?

[sphh]

@kokosowy: Please see the discussion to PR #6 (and the solution here: #6 (comment)).

I'll add it to the next release.

[mikiair]

@sphh I put this here, as it refers to work-in-progress v0.2.3: It seems that last commit cffb7d is not working properly.
I have set save_on_events = volume_changed,track_playback_started and playback.state = playing in my mopidy.conf. I intend to restore the last played radio stream and the last used volume, plus forcing automatic playback when system starts. However, the playback state gets currently overwritten on system start and stays at paused until I trigger playback from an external client app (looks like it happens everytime so far).
I will try to dig deeper in my log files when I find the time. Maybe I can identify the critical sequence somewhere at start-up.
Possibly there is a way to handle on_event and trigger the timer only after complete system is up and working?

[sphh]

A couple of things:

• Have you read https://github.com/sphh/mopidy-autoplay#readme?
• And that lengthy discussion here: Issue with the local media and ytmusic #3

If it due to these problems, you should see a message in the log file (b1095e7) along the line:

Tracklist abc:xyz loaded into tracklists, but it cannot be found there! Possible reasons are:
1. The track has disappeared.
2. The backend 'abc' does not exist.
3. The backend 'abc' is not ready (yet).

BTW which backend do you use?

If that does not solve your problem, could you please open a new issue?

[mikiair]

Yes, I read the readme before, but I should have made sure that core/restore_state is really set to false! Sorry!
I have corrected this now, and after restarting mopidy several times, it works as expected.
Backend is just Mopidy-Stream playing some http radio stream.
I wonder a bit about the sequence of events when restore_state is set true:

1. Mopidy and its extensions got loaded etc.
2. Autoplay reads the config, triggers playback paused --> playing, which is confirmed in the log by several status events.
3. Only after 8-10s some message from the core (?) shows up and stops the playback again.
   Don't know where this comes from, but at least I would exclude now that it is related to Autoplay.
   I do not see the detailed message from above anywhere in the log.

[sphh]

I believe all that comes from the threading in Mopidy, so there is no predictable order in loading extensions (or the core), especially one cannot be sure, that all extensions have been loaded (not even the core can do that). At least that is my understanding.

You would only see that detailed message, if the backend is not ready yet and autoplay wants to play a stream.

Do you have another extension, which wants to play something? autostart? alarm clocks? sleep timers?

[sphh]

This repository has been moved to https://codeberg.org/sph/mopidy-autoplay/ and this one set to read-only.

Please continue at https://codeberg.org/sph/mopidy-autoplay/issues/4