New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Seekbar does not work. #275
Comments
Thank you for the report! Unfortunately I cannot reproduce the error; I've streamed a flac file and I could seek within the file (at least as far as the file was already transcoded) could you please provide additional information?
|
I will provide additional information.
Download cherrypy now? (y/n)y You seem to be missing the optional module "stagger", an ID3-tag library. You should install it using the package manager of your OS. Alternatively cherrymusic can download it for you and put it in the folder in which cherrymusic resides. Download ID3-tag library stagger? (y/n)y Downloading cherrypy... Extracting /tmp/cherrypy.tar.gz Copying cherrypy module inside cherrymusic folder (/home/username/cherrymusic)... Cleaning up temporary files... Downloading stagger... /home/username/cherrymusic/stagger/__init__.py /home/username/cherrymusic/stagger/commandline.py /home/username/cherrymusic/stagger/conversion.py /home/username/cherrymusic/stagger/errors.py /home/username/cherrymusic/stagger/fileutil.py /home/username/cherrymusic/stagger/frames.py /home/username/cherrymusic/stagger/id3.py /home/username/cherrymusic/stagger/id3v1.py /home/username/cherrymusic/stagger/specs.py /home/username/cherrymusic/stagger/tags.py /home/username/cherrymusic/stagger/util.py done Successfully installed cherrymusic dependencies! You can now start cherrymusic. Please see the attached picture for details. |
I could now reproduce the problem. It is due to the way chrome handles an mp3 stream. Firefox thinks of the stream as a unfinished download, so seeking is possible within the downloaded part of the audio. chrome thinks of it like an mp3-radio; It doesn't make sense to seek within a radio stream, since it is neverending, so chrome prevents that. I'll try to find a solution, thanks again for the detailed report! |
I can confirm this issue, but with firefox 24.0 |
@Notmarrco, thanks for the report, but I can not reproduce this with firefox 24. Is your server fast enough to transcode the file faster than the playback speed? And is the server upstream connection speed faster then the standard transcoding quality (160kbits for mp3 / 128kbits for ogg)? And also, what OS are you using? EDIT: You can test the above by starting to play a transcoded track and then pausing. The track should then be cached and allow you to seek to another position. |
Good idea, I tried it then. |
ok, I updated from squeeze to wheezy and installed python3, and updated to ff25, and it works. |
Okay, so the problem is still only affecting chrome; Thanks for rechecking with up-to-date software. We essentially also know how to fix the problem completely, but this is a rather complex issue. I tried to tackle from different sides multiple times; The easiest implementations either use up a lot of memory or disk space or just suck. Anyway, I'll try to explain what's going on under the hood and why chrome doesn't play ball. Maybe someone takes this as a programming challenge 👯
Transcoding works like this:A client requests a track from a special URL, which contains the original track and the desired transcoding format, e.g. In the backend, this lets the audiotranscode module kick in. I starts a process usings pythons This continous output (a generator, to be specific) is used in Now to the problem: Normally a HTTP response has a This is all nice and good for firefox, since firefox assumes that the file is just at least as long as all the files it received so far. This is why you can only seek within the parts that are transcoded so far. This is not optimal, but not to bad either. Chrome on the other hand assumes that a http stream (a http response without a length) is a neverending continous stream (like a internet radio) and should not be seekable. This can be overcome by giving chrome HTTP partial requests, since you can always reset the final content-length in a later packet, so we can trick chrome into behaving the same as firefox. Is there a remedy?What didn't quite work: I've tried to estimate the length of encoded files, but I was always off by some bytes, which led to tracks being cut off at the end or the player hanging, because it still tried to receive the last non-existent bytes. Furthermore this leads to wrong time-length calculations on the client side. What might work: I tried to send HTTP partial requests and always send all the available data, but tell the browser that there is some more (lets say 10 bytes more) than I just handed over, so that the browser will request those 10 bytes when they are needed for playback. Once the transcoding is over, we can just tell the browser the real length. You could think of this approach as something like an adaptive estimate. What would be the elegant and correct thing to do: Always stream everthing; Files are no longer served staticly, but instead are always streamed. There is no notion of bytes or anything in the player: There is only time. So all the client needs to know is the file it wants to have and its length in seconds.
|
This change adds support for cuesheets by passing a track parameter around which indicates which track in the cuesheet should be played. The actual audio file is split with ffmpeg using the -ss and -t parameters, which are filled by the decoder when the file extension is '.cue'. cuesheet.py is added to parse cuesheets. This is taken from a separate project so it's a bit messy and contains some stuff that isn't used. Metadata is also fetched from the cuesheet per track.
I also have this issue, chrome. |
Same here with flac files:
|
same here with chrome, flac and mp3 won't seek if you would go with estimating |
Seekbar doesn't work when CherryMusic to play a flac file.
And the track length is 00:00.
Errorlog was not displayed.
The text was updated successfully, but these errors were encountered: