Bugzilla – Bug 571
Transcoded files cannot FWD / RWD
Last modified: 2009-07-31 10:13:35 UTC
Holding down forward or rewind does not skip playback within a WMA song. All I can do is skip whole tracks. Using latest release. I have checked and yes, MP3's do allow skip. Which debug commands can I use to show what's happening?
This is by design. WMA is not native, and is transcoded. Thus far, transcoded files cannot be scanned because they are streamed to WAV or AIFF on the fly. Also, this is not squeezebox or firmware related. changing to slimserver and marking as an enhancement request.
Please can we have WMA decoding in hardware in the SB?
Until we have WMA in hardware, we should be able to do a silent scan forward/backwards and then start playing from the appropriate place.
great!
as long as gotoTime is supported when transcoding, the song scanner plugin would work as well
I'd like to see the functionality of the songscanner plugin added to the main server so that users can seek within any capable file format.
where would you like it added? ti could be just an included plugin, or merged in somehwere else if there is a better place. I'll attach the current plugin.
Created attachment 167 [details] scanner plugin
Is this fix now live?
when you get an email saying this bug is marked fixed, that is when it will be live.
Marking items that aren't going to be addressed immediately in 6.1 as future. Please update if this is in error or the bug has already been addressed.
*** Bug 1791 has been marked as a duplicate of this bug. ***
requires native WMA, request bug 1763
This is still a problem with SlimServer 6.2.1, which supports WMA natively: the fast-forward and rewind operations "appear" to work, in that the sb displays "scanning x2", but the little bar indicating position in the track does not move, and pressing play again does not restart the song. Pressing play a second time restarts the track at the beginning. The song scanner plugin behaves in the same way. Both the song scanner plugin and the built-in ffwd/rwd support work fine for MP3 files for me. I suspect this does not work for anybody, but please let me know if you have trouble reproducing the problem and I can send debug logs, etc.
I'm experiencing the same behaviour as reported in comment #14, but with 6.2.2 - 5441 - Windows XP - EN - cp1252 (which I think was the 2005-12-27 nightly); however I haven't tried the song scanner plugin. I observe that in Server Settings / File Types, all four options for WMA are checked. I tried unchecking all but the "(built-in)" one, but this made no difference. (At least, not when I played another WMA file and tried to fast-forward; should SS be restarted after changes to the File Types settings?)
I ran across this bug in slimserver 6.5/fw 60 while working on bug 2985, as well.
This bug is still present in the latest supported release of the 6.5 software (SlimServer Version: 6.5b3 - 9697 - Windows XP - EN - cp1252). This is to be expected, I know, since the status of the bug has not changed. Since I have ripped all my CDs (800+) into WMA I am eagerly awaiting a fix - so far all other bugs that I have seen (and feature requests for that matter) have been fixed within weeks after they have been reported, and my enthusiasm about the product has just increased (I now own both a SB2 and SB3). By the way, thank you for giving us Wake on LAN, fixing the "song does not play complete but stops after 2.08 mins", the Squeezenetworks for my playlists containing Internet radio stations, fixing the "Browsing always starts at Various Artists" in 6.3 etc. etc. - I really love this product and the effort you are putting into making everything work!! Given the latency on this bug I suspect that it is not easily fixed, and what I really would like to know is: Can/will it be fixed in 6.5? (I know this can be a tricky one to answer) The main reason I am asking is that if not, I will consider ripping or converting all my music into MP3 instead, but I do not even want to think about how much time this process will take... :-(
(ref support ticket 070508-002019) Dan Evans here: a customer wrote in saying he was unable get REW/FWD scanning to work on WMA files so I tested it here. I confirm the same-- attempting to scan forward stops the song even while displaying "2X" etc. The timer does increment forward as though it were scanning, but there's no audio and pressing PLAY does not continue the song playing.
Should this be assigned to Richard, Dean?
Alan says just look at how ogg does it.
It kinda sounds as though when/if this is resolved it would do so for all transcoded formats -- is that right? I'm specifically interested in Apple Lossless.
No, it is dependent upon each individual source format, especially with the new-streaming functionality planned for 7.2. The relevant format-handlers would need to be extended to support findFrameBoundaries() and getInitialAudioBlock(), assuming that these two mechanisms are sufficient.
*** Bug 8620 has been marked as a duplicate of this bug. ***
For completeness, my comment from bug 8620 (which was dup'd to this bug): Apple Lossless, like other non-native formats, cannot fast forward/rewind. Some of the discussion in Bug 571 seems to indicate that there is some hope for fixing this. I would guess there are quite a few people who would benefit -- basically anyone who manages their library with iTunes and uses a lossless format. (The hack I briefly considered implementing is simply to transcode to a temp file instead of a pipe, and then have slimserver play back the temp file which would of course be in a native format and therefore support FF/RW. I assume there is some good reason this simple expedient has been rejected.)
For what it's worth, I have been waiting for this bug to be fixed ever since I got my first Squeezebox 3+ years ago, and it's my single biggest request (I'm using wma's). Is there hope that this will in fact be addressed in the near future? thanks!
In SC 7.1 fast fwd/rew will, in general, be replace by scanning (SongScanner). In SC 7.2, the generic restriction on scanning transcoded files and remote streams will be removed. Some formats will still not support scanning, either because no-one has implemented the necessary support or because of other restrictions. WMA is particularly problematic because of the license restrictions associated with Microsoft's ASF format (the container format used by WMA files) - I understand that this license, if Logitech had one, is not compatible with OSS (GPL) software such as SqueezeCenter. Similar issues exist with AAC. For unencumbered formats, patches to add support for findFrameBoundaries() and getInitialAudioBlock(), as appropriate and assuming that these two mechanisms are sufficient, are welcome. Of course, these will only be effective from SC 7.2.
Not that this bug report should develop into a thread in the forum but... I too have been missing this functionality since my first SB2 several years ago, have reported and voted for this bug and even considered throwing a small party when I saw the target release for a fix was present (currently 7.2). Since I am using WMA files I am a liiiiiittle bit worried about this comment: > WMA is particularly problematic because of the license restrictions associated > with Microsoft's ASF format (the container format used by WMA files) - I > understand that this license, if Logitech had one, is not compatible with OSS > (GPL) software such as SqueezeCenter. Does this mean that it will not be possible to use FF/RW with WMA files, even when 7.2 is released? Or will it just mean that you clever chaps will demonstrate exactly how good you are at making things work despite Microsofts best efforts? ;-) BR, Claus
Target milestone now 7.3? :-/
Fixed by new-streaming changes in 7.3
Seek support is limited to specific source file/stream types:- * local files: o WAV - only when transcoded to FLAC, which is the default, o MP3 (with or without further transcoding), o FLAC (with or without further transcoding), o Ogg (with or without further transcoding), o Wavepack (always via transcoding); Note that seek support for local WMA files has not been added and is unlikely to be (patent issues). The transcoding framework allows transcoders to be configured with seek capability for arbitrary formats. The list above represents the default configuration. * remote streams (only fixed-length streams - podcasts and the like, not live streams or streams of undetermined duration), dependent upon support by the remote server (stream source): o HTTP/MP3, o MMS/WMA (strictly speaking, o Rhapsody.
This bug has been fixed in the 7.3.0 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.
Apple Lossless still doesn't work. It sounds as though this is as expected. Either this bug should be reopened, or bug 8620 should be un-dup'd (see my previous comments on this bug), or a new bug opened to track Apple Lossless.
I just opened bug 10343 to track the fact FWD/RWD still doesn't work with WMA.
Reduce number of active targets for SC