Bugzilla – Bug 7470
Podcast Time Played/Remaining off on various UIs
Last modified: 2009-07-31 10:17:51 UTC
The time played and remaining time feature on Podcasts is off quite a bit. It appears that it does not accurate calculate the time played when going to the next podcast in the playlist It appears that the time remaining is not properly calculated at the start of the podcast and is improperly calculated during the duration. For example I played a Foreign language podcast that was 20 minutes long. After a minute or so the time remaining was not decreasing to 19 minutes. It was still in the 20 minute range. This continued and by the end of the podcast the time remaining was 24 minutes while the time played was at 20 minutes. The problem withe the time played when skipping to the next podcast in a playlist is that it continues with the previous time played and does not reset. It continues to increment for example to 20:01 instead of 00:00 and also the time remaining is at the previous entry and does not reset
Please specify a sample podcast URL that exhibits this behaviour.
http://lukevenk.audioblog.com/rss/lost_podcast_with_jay_and_jack.xml
Confirmed, the below listed podcast does show 0:00 for duration, SC 7, SB3, SB Controller UI. Note: On the Controller UI, it does properly display elapsed duration, but the remaining duration. Remaining duration starts at 1:59, counts down to 1:30, then jumps back up to 1:59. Unable to reproduce this with other podcasts at this time. Are there any specific logs you would need to diagnose this issue?
It seems that Slim::Music:Info:setRemoteMetadata() can sometimes be called from XMLBrowser with secs (track duration) specified in hh:mm:ss format. Only plain seconds is expected. I do not know if this is a protocol error on the part of the remote source but it seems reasonable to handle it in any case. The various UIs do not handle this situation well. Fixed by change 18191. Note that you will need to rescan your library if you want to clear the data about already-played items which will now have incorrect data in the database.
Verified fixed in 7.0.1 - 19325 Please reopen the bug if you see any other podcasts with this error. Please include details as well as sample links.
This bug has recently been fixed in the latest release of SqueezeCenter 7.0.1 Please try that version, if you still see the error, then reopen this bug. To download this version, please navigate to: http://www.slimdevices.com/su_downloads.html
Reduce number of active targets for SC