Audiobook saved position sometimes ignored after MM restart

Post a reply

Smilies
:D :) :( :o :-? 8) :lol: :x :P :oops: :cry: :evil: :roll: :wink:

BBCode is ON
[img] is ON
[url] is ON
Smilies are ON

Topic review
   

Expand view Topic review: Audiobook saved position sometimes ignored after MM restart

Re: Audiobook saved position sometimes ignored after MM rest

by sialivi » Mon Aug 12, 2013 2:34 am

Surely it can be addressed by simply re-ordering when the resume information is read?

Re: Audiobook saved position sometimes ignored after MM rest

by Peke » Sun Aug 11, 2013 9:00 am

I can add it but there is nothing we can do as you are starting track playback before MMW loads playing list and read Resume place.

Re: Audiobook saved position sometimes ignored after MM rest

by sialivi » Sat Aug 10, 2013 6:45 am

Any chance of getting this added to Mantis?

Re: Audiobook saved position sometimes ignored after MM rest

by Peke » Sun Jun 30, 2013 7:15 pm

MMW can't resume playback until Status bar do not shows Reading tracks.

That is when your Sometimes occur.

Audiobook saved position sometimes ignored after MM restart

by sialivi » Sun Jun 30, 2013 12:42 pm

Sometimes when resuming playback of an audiobook after restarting MM, the saved position is ignored and playback starts from the beginning of the file.

Steps to reproduce (might take several attempts as it doesn't always happen):
1) Start playing an audiobook and jump a head in the file long enough for the position to be saved
2) Restart MM
3) Not sure if this step is required, but on my system I have quite a lot of music folders that are being monitored by MM so a fairly long running scan starts at this stage
4) Press Play right away (while the scan in step 3 is still being performed) to resume playback of the audiobook
5) Result: Sometimes the playback will start from the beginning of the file, not from the saved position

My guess is that the saved position hasn't been read yet when pressing play too quickly after a restart, and that this saved position data needs to be prioritized higher and read right away.

I'm using build 1644, but this bug has existed for a very long time.

Top