Bugzilla – Bug 6905
Direct Seek using the Web Interface does not work with 88.2Khz FLACs & Transporter Firmware r40
Last modified: 2009-07-31 10:16:39 UTC
With great joy i upgraded to the latest SC (currently r17103) including the Firmware r40 for my transporter. Now i can fully enjoy all those hi-res music tracks. As i don't need to transcode my flacs anymore i can use the webinterface for direct seeking within a track. This works fine for all formats with one exception i've found: 88.2/24 flac files Clicking on the progress bar always restarts the track although the progress bar on the webinterface and on the transporter (key PROGRESSBAR) is correctly displaying the new position. I did a "wipe and rescan"... I'm not sure if "SqueezeCenter/Slimserver" or "Transporter" is the correct category for this report so please feel free to move it whereever you wish... thanks once more for this upgrade! kind regards, Markus
I'm pretty sure this is a slimserver bug. I would guess that it does a calculation depending on sample rate and is not handling the new case.
no new facts, but get it documented anyway: the SBC (running 7.1/r2415 on SC 7.1/r19296) has the same problem with 88.2 files. The Bar shows up, using the wheel i select the desired position but the track always (re)starts from the beginning kind regards, Markus
This may have been fixed since you filed this bug. I can seek perfectly in both 88.2k and 96k FLAC files on both SB and TP.
Created attachment 3432 [details] Debug Logfile when seeking through a 88.2kHz track
Created attachment 3433 [details] flac info (metainfo --list) of this track
sorry it took so long but i still have this problem (as of 7.1r20756) I created some logs with player.source + player.streaming = DEBUG (squeezecenter-seek.log) and such a problem file (metaflac-list.log) If you like to have a deeper look at this track (70MB from Linn Records, i failed to attach it to this bug as you may have noticed ;-) i uploaded it to my personal webspace and could email you the location.
Yeah, I guess there is something different about your file than mine. Please send me the link to your file.
Fixed in 7.1 change 20843. We weren't reading the frame header properly when the sample rate was 16 bits and stored at the end of the frame. My 88.2 file was made with a newer encoder and so stored the sample rate in a different location.
confirmed. no problems anymore. thanks! btw. foobar+linn say this is a 24bit file.
Yeah, I meant the sample rate field in the frame header was stored using 16 bits, not that the file had a 16-bit sample rate :)
This bug has now been fixed in the 7.1 release version of SqueezeCenter! Please download the new version from http://www.slimdevices.com 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.
Reduce number of active targets for SC