resume spotify doesn't work most of the time

[jlarsch]

Hi, I built a phoniebox with spotify support, 3 buttons, rotary encoder for volume and everything works like a charm, except the 'resume' function with spotify playlists. After setting up a new RFID card with a spotify playlist, I toggle the 'Resume' button in the browser app for that card. Now, my son listens to these audiobooks that are spotify playlists of hundreds of individual 'songs'. Even with 'Resume' set to 'ON', most of the time after the phoniebox is rebooted, the playlists starts over from the beginning. A few times the playlist actually resumed (not quite at the same place where it had ended, maybe one track off, but OK), but on those occasions, it stopped playing after a minute or two and needed a reboot - at which point the position was lost again. I can't reproduce when it works and when it doesn't. Should I follow a particular shutdown routine? I usually just turn off the box by cutting off the power via a switch that I put between battery pack and raspi, maybe that doesn't allow Resume to work? Could this be improved? With these very long audiobooks, finding the right track takes forever and currently, I end up having to find the right track through the browser-app. My kid can't do that alone, which sort of defeats the purpose a little bit.

here some info on my system:

System OS Distribution Raspbian Description Raspbian GNU/Linux 10 (buster) Release 10 Codename buster Phoniebox Setup Version 2.0 - ed888da - master Edition Plus edition (feat. Spotify integration) Mopidy Server Status active (running) since Sat 2020-07-18 14:34:18 BST; 6h ago

thanks in advance!

[s-martin]

I think when you just cut of power it won't work, because the Phoniebox software doesn't get an indication that the power will be switched off and therefore can't store the actual position.

You can

• Shutdown via web UI
• Shutdown via a RFID card registered to the system command to shutdown
• Use a GPIO button for shutdown (see wiki)

[jlarsch]

I think there is actually a bug here, or at least unexpected behavior: Of course you are right that cutting power is going to be unexpected to the box, but that alone is not the issue here. I did some troubleshooting:

I monitored the file folder.conf in the folder of a playlist. That file and its row 'CURRENTFILENAME' is indeed not updated during regular playback. But it does update once a second card with a different playlist is swiped. Now when I swipe the first card again, the box starts playing the last track of the first playlist but then stops playing once that track is finished, even if there are many more songs after that in the playlist. Once it is in that state, I found no way to resume playing the playlist, except restarting it from the beginning.

1) I think this is a real bug. At least for spotify playlists, 'Resume' only resumes and finishes the last song but then gets stuck for some reason. I noticed also that the browser app shows the player in a weird state after 'Resume': The play button isn't active and the timer that tracks elapsed time for the track isn't updating as it usually does.

2) Also, a related but separate issue concerns specifically Spotify playlists as opposed to albums. Spotify playlists typically consist of tracks from a number of different albums. I noticed that folder.conf doesn't actually save the playback position in the playlist, but instead saves the last track name. Therefore, upon 'Resume', playback resumes by playing the track from the album and seems to forget that it was playing a playlist. If this is actually the case, I conclude that 'Resume' is currently not compatible with Spotify playlists?

3) If the issues above can be sorted out, would it make sense to include a few more occasions when the box saves the CURRENTFILENAME? For example after each completed track, or after a fixed time interval for example?

[MiczFlor]

Hi @jlarsch

the CURRENTFILENAME issue is actually desired behaviour :) for local files, this is only saved if the current playlist is properly "stopped" or replaced by swiping for another playlist. Behaviour such as "pause" does not save the CURRENTFILENAME. Adding more occasions would not change anything because CURRENTFILENAME is only needed if Phoniebox comes back to a previously played playlist AND sees that the behaviour is set to resume. In this case, it needs to know where to resume from.

The Spotify behaviour is mostly out of our control. It would make more sense to compare Spotify and Google Music in its behaviour than comparing Phoniebox with local files and Phoniebox with Spotify.

So why the Spotify playlist stops after one song when you resume a playlist... difficult to say. Could be Spotify API or could also be mopidy, which we are not in control of either.

Possibly the collective feedback helps to pin this down. And if other people would report their behaviour in this thread. There have been relatively simple fixes at times, not because of digging deep into code, but because many people tried many things. And one thing worked :)

[jlarsch]

Thanks for the reply! I understand a bit better now how CURRENTFILENAME was designed to work (update when properly stopped but not when paused). In my experience, the kids don't properly stop a playlist, they just turn off the box and then CURRENTFILENAME isn't set. This is why I thought updating CURRENTFILENAME more often would help after a hard shutdown when coming back to a previously played playlist that is set to RESUME.

[jlarsch]

seems like others had similar issues #810 which was fixed on mopidy 3. However, I am on 3.0.2 already:

mopidy --version Mopidy 3.0.2

[s-martin]

What's the output of journalctl -u mopidy after you experienced that behavior?

[s-martin]

seems like others had similar issues #810 which was fixed on mopidy 3. However, I am on 3.0.2 already:

mopidy --version Mopidy 3.0.2

I suppose you built this box recently and didn't upgrade from a older version using Mopidy 2?

[s-martin]

Do you still experience this issue?

[s-martin]

Hi, #1149 was merged to develop to fix #878. Could you check, if this fixes your issue.

[s-martin]

Closing. Feel free to reopen, if the problem still occurs.