Bugzilla – Bug 10419
FWD/REW (scanning) broken for remote tracks
Last modified: 2009-07-31 10:33:39 UTC
The changes to the transcoding framework have broken scanning for remote tracks. This is because the decision as to whether a track is seekable is made before starting to stream the track. In turn, this is on the assumption that the pre-scan (Scanner/Remote) will have set the duration in the DB, but in fact this only gets set when we start streaming. Andy, is there any good reason why Scanner/Remote could not set this info?
Yeah I think the scanner should be responsible for this, I'll take a look.
Can't seek podcasts here. But is this the same issue with the iPlayer plugin too (i.e. any remote file)?
Created attachment 4495 [details] Proposed fix
I expect the iPlayer and AlienBBC plugins may need updating. Not sure which yet.
That looks OK, I am not sure we need the Content-Length code in the icy-br block, that should only be set for live streams.
But that is where the bitrate is set, and hence where the duration could be worked out from the length.
Actually, it looks like Alien is working fine wit this fix. iPlayer may be different - I cannot test it here.
Alan - users of iPlayer (and I) report scanning being possible via the web interface, but not via the button mode interface sometimes. Is this potentially related to this?
I cannot see how it would work in one interface but not in others as the decision is first made in Song and then cached.
Well it looks like iPlayer now no longer has the random problem with scanning - it won't do it at all! Is there no way we can avoid making the decision early and use the headers returned when we play the stream to set the bitrate and length? The reason iPlayer can't use this is that the scanning code does a normal http request using a standard request header and hence doesn't use my protocol handler. I think the approach you have now restricts the ability to extend this via protocol handers...
triode, do you try the idea of setting the flag directly, as we discussed?
Change 24413. Andy, I took out the icy-br clause setting of duration.
Andy, I'm not really comfortable with the structure of Remote::parseAudioData(). It goes to the trouble of scanning the stream data for the bitrate and then only sets this, and now the duration, in the DB if the bitrate was not already known. Either we should not scan for the bitrate if we are not going to use the acquired info, or we should use it even if we think we already know it. Also, it sets the Track filesize field in this method, even though that info was known in readRemoteHeaders(). A separate issue is the way we call all the Slim::Music::Info methods for each field we want to set, causing a separate DB transaction each time. It would be better if we could bundle these up into a single call.
Alan - looks like it works if I just set the canSeek flag to undef during header parsing, meaning that the originally cached value is not retained and we can update the bitrate/duration at stream start time. Could this be used in the general case - i.e. don't cache until after the track is actually streaming and you have read the real headers of the stream?
I'm not sure that there is an easy way to determine that. However, a suitable general API call might be Song::resetCanSeekCache().
Alan - actually this doesn't work so easily in all cases. For the direct streaming case the parseDirectHeader call includes $client so I can do this, for the proxied streaming case, parseHeaders doesn't include $client so I can't do this as I can't get to the song object. There is a status variable in the song object - can this be used to restrict when the cache is started, otherwise can we look in $owner for this? I think this is the streaming controller and it should know if we are streaming or not?
Alan - turned out to be easier to fix iPlayer - as this can always seek for streams via the protocol handler I'm just including a canSeek method which always returns 1. It seems ok to update the bitrate and duration later, but we always need to set can seek correctly the first time as it is cached..
Great.
I'm a little unclear on the status of this. It is set to RESOLVED/FIXED, though it looks like some details of the solution are still being discussed. Would the proposed fix be found in any recent nightlies?
Yes, it is fixed and the fix has been in the nightlies since Christmas. There was some additional discussion about the impact on iPlayer but this has also been resolved.
Thanks for the clarification. I've downloaded the nightly and it certainly seems fixed now.
(In reply to comment #21) > Thanks for the clarification. > > I've downloaded the nightly and it certainly seems fixed now. > verified fix in SqueezeCenter 7.3.2 r24679
Fixed - Closed Message (SC) This bug has been fixed in the 7.3.3 release version of SqueezeCenter! Please download the new version from http://www.slimdevices.com/su_downloads.html if you haven't already. If you are still experiencing this problem, feel free to reopen the bug with your new comments and we'll have another look.
Correction: SqueezeCenter version is 7.3.2
I'm not sure if it's the same bug, but I am running version 7.3.2 - 24695 and still getting "CANNOT SCAN THROUGH REMOTE TRACKS" message on the display of my Sqeezebox3 when trying to fast-forward or rewind. But this only happens on mp3 files which have a .cue file associated with them (logical breakdown of tracks within a long mp3 file). This used to work properly in old SqueezeCenter version (6.x). I initially thought this bug was supposed to fix just that. But now I see you guys closed it, yet I am still having the problem. Thanks.
Pete, That sounds like a different bug, even if the error message is the same. Please open a new bug for that specifically.
Done. https://bugs-archive.lyrion.org/show_bug.cgi?id=10805 Thanks, Pete
Reduce number of active targets for SC