🐛 | Resume starts song at the beginning and only then jumps to current index

[albert0815]

Hi all,

First of all thanks to all of you contributing to this project. I really enjoyed building the Phoniebox and my son loves it. The idea and its implementation is really great!

I have a minor problem which I would like to place here as a bug. I am happy to contribute as well if somehow possible.

Bug

Currently the resume functionality is a little broken. It first starts at the beginning of the title and only then jumps to the specific index. This is a really weired and unexpected behaviour. I understand that it was introduced to fix a bug which seems to be related to Spotify with PR #1149. In the description of the workaround the behaviour is even mentioned. On the one hand side I understand that a somehow working resume functionality is better then no resume at all. But for my purpose this workaround is making things worse. I tried reverting the change and the resume works perfectly fine (with just MP3 files). So I assume the workaround is only required for Spotify.

What I did

Installed 2.2 with oneline installer on Raspberry 3b (Hifiberry MiniAmp, OnOffShim, RC522, no GPIO buttons). Uploaded MP3 files and configured the folder to use resume functionality in the web ui.

What happened

Whenever I start a MP3 using a card which has resume enabled the first half second is played and only then the playback jumps to the correct sequence.

I expected this to happen

Immediately start at the correct index.

Further information that might help

Reenabling this line in the resume_play.sh makes everything behave fine again: echo -e seek $PLAYLISTPOS $ELAPSED \\nclose | nc -w 1 localhost 6600

Software

Base image and version

PRETTY_NAME="Raspbian GNU/Linux 10 (buster)" NAME="Raspbian GNU/Linux" VERSION_ID="10" VERSION="10 (buster)" VERSION_CODENAME=buster ID=raspbian ID_LIKE=debian

Branch / Release

pi@raspberrypi:~/RPi-Jukebox-RFID $ git status | head -2
On branch master
Your branch is up to date with 'origin/master'.

Installscript

scripts/installscripts/buster-install-default.sh

Hardware

I don't assume any dependency of this issue to my hardware. Please let me know in case you need more details.

[s-martin]

@albert0815, thanks for investigating this issue and finding the root cause. Just to confirm, did you test that with Spotify or classic edition?

@StefanMinke can you confirm that the fix #1149 was intended and works for Spotify?

if that’s the case we could try to handle Spotify and classic edition differently in resume_play.sh.

[StefanMinke]

Martin, thats correct and works for me as indended. But you are right, I havent tested the resume function with local files.

Maybe youre right an the seek command will work with local files, but not with spotify playlists.

[albert0815]

I can confirm that I am using classic edition without Spotify and seek command is working fine with local files.

[s-martin]

So is the difference local files vs. streams or is the difference classic edition (MPD) vs. Spotify edition (Mopidy)?

[StefanMinke]

currently I cant check whether resuming local files in spotify edition works well with the seek command. I can try it in about 1 week and will report, if nobody else did before.

[StefanMinke]

Hi. Big SORRY for the very late response. :-/

Resuming local files with the seek command doesn't work either.

So the workaround is absolutely suitable for this version.

Whether this patch is also neccessary for the classic version has to be checked by someone who uses this version. ... aaah... albert already did it.

So it seems to be a problem only with the spotify version (mopidy).

[schuenep]

Hi, I experience this problem as well using the Spotify version while resuming Spotify or resuming a Webradio stream. Any plans to fix this bug? Thanks to all contributors of this project :)

Edit: I am using version 2.3

[schuenep]

Hi, I am currently testing to call mpc directly. This seems to have a significantly reduced delay so it is not hearable (for me) that the song is starting at the beginning and then skipping to the position. mpc play expects song index to start at 1 and mpc seek HH:MM:SS format for position though, therefore the two extra lines.

Let me know what you think. I could create a PR for this.

#echo -e "play $PLAYLISTPOS" | nc -w 1 localhost 6600
#echo -e seekcur $ELAPSED \\nclose | nc -w 1 localhost 6600
HHMMSS=$(date -d@$ELAPSED -u +%H:%M:%S)
PLAYLISTPOS=$((PLAYLISTPOS+1))
mpc play $PLAYLISTPOS
mpc seek $HHMMSS