Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Can't pause during mp3 stream playback. (Read 1068 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Can't pause during mp3 stream playback.

- foobar 2.0 (32bits) - last version
- Small mp3 correctly coded file serviced by simply HFS
- fb2k grabs it super quickly but when fb2k un-pauses, it requires again the full resource with a simple GET (no range of any kind). I've tried with servers that all do accept-bytes and got the same => fb2k restarts the track from zero. In summary, I can' pause *and resume* a mp3 that is streamed by a HTTP server.



Re: Can't pause during mp3 stream playback.

Reply #1
If there is no content length, foobar2000 assumes remote MP3 resource to be a live radio stream. You can't really pause these.
I'm not changing this behavior. Please fix your server.
Microsoft Windows: We can't script here, this is bat country.

Re: Can't pause during mp3 stream playback.

Reply #2
Just for clarity, I'm using foobar2k for my own (all free) applications as one of my key validation vehicle, not as a listener, hence some questions that might be a bit unusual.

The problem I was seeing only with 2.0 and not 1.6 was (mainly) due to the fact that I accidently removed the "allow HTTP seeking" in 2.0 and it was preventing fb2k from pausing even with content-length.

Now, I'm surprised by your answer because I do think that no content-length, especially with UPnP is not a cause for treating resource a webradio and not pausing, or is indicative of a wrong server.

- a HTTP 1.1 server can use chunked-encoding and in that case there must be no content-length
- a server might be transcoding a file on the fly and does not know the file size in advance. The file can be huge
- in my case, it's a bridge between different domains and it does transcoding, so I really can't know the size

Just plain HTTP would allow to do range-request and that would still allow pause/resume if the server can handle these (especially if it says "accept-range: bytes", it should). Also, in UPnP/DLNA, there are various mechanism where the server tells if the content is seekable. It can have a duration and/or have the DLNA_ORG flags that contains FLAGS and PN for this purpose. There is also a "connection stall" flag that indicate the client it can leave the connection open while pausing.

So to me, closing and then re-issuing a GET with no range when there is no content-length seems an un-necessary restrictive approach (even in a non-UPnP case which I agree is a different problem by itself). The server can always ignore the range request and provide the resource from where it wants (or do a 416). No content-length is really no a valid indicator of webradio/live streaming, IMHO.

Just for clarity, I'm not criticizing fb2k or do any sort of "request", it's just a dev-to-dev conversation as someone that use and likes fb2k a lot.

[edit]: one difference I've noted between 1.6 and 2.x is that mp3 files, when no HTTP seeking is allowed, in 1.6 were l showing position/duration. In 2.x, they just show position (progress)

Re: Can't pause during mp3 stream playback.

Reply #3
Something also I forgot to ask: fb2k "probes" mP3 files when there is a content-length (and it is authorized to do HTTP seek). Is there a specific reason for that?

Thanks

Re: Can't pause during mp3 stream playback.

Reply #4
Just for clarity, I'm using foobar2k for my own (all free) applications as one of my key validation vehicle, not as a listener, hence some questions that might be a bit unusual.
Good to see it getting a refactor.

 

Re: Can't pause during mp3 stream playback.

Reply #5
Something also I forgot to ask: fb2k "probes" mP3 files when there is a content-length (and it is authorized to do HTTP seek). Is there a specific reason for that?
Missing Xing header, so guessing duration