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: Seeking in HTTP files (Read 5081 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Seeking in HTTP files

WHEN is this going to be implemented?! It's soooo annoying!

Seeking in HTTP files

Reply #1
how is that going to work?

when you listen to a stream you can always only listen to that part that is being streamed right now...

you could seek backwards, if the player saves the file tho... but thats all i can think of

Seeking in HTTP files

Reply #2
I think its possible but not all streaming servers has that function enabled.
I was testing that long time ago with winamp and streams from mp3.com and seeking of tracks was avalible.

Seeking in HTTP files

Reply #3
Erm....


Simple way: if the server responds with a content-length header, you know the file is "on demand" and not streamed.

ie. I upload a file called foo.mp3 to my webserver, load it in foobar, and should be able to seek through it the same way i would seek through it locally.

try it in winamp.

I gave you lot more credit than that

Al

Seeking in HTTP files

Reply #4
IMO it's not possible because Foobar has implemented sample-exact seeking in mp3 files. And a such ability would be a hack which is not allowed.

Seeking in HTTP files

Reply #5
the only thing that I really miss is seeking in http stream.

winamp and windows media player can do it either with mp3 or ogg files.

so we know it's possible...

I got all my mp3 and ogg files on my intranetserver.... they are stored under netjuke...( a really lovely php program --> www.netjuke.org )

it is a pity that in this case foobar is useless at least for me....

Seeking in HTTP files

Reply #6
Yeah its relative easy when you perform your HTTP Get request you use the 'Range:' header to request a sub-set of the whole content (this is obviously a HTTP1/1 feature).  Does anyone know if this has been implemented yet as I'm getting requests to support it on my plugin, (wombatshare) And I'd rather no re-invent the wheel

edit: Hmmmm just been looking through http.cpp looks like it does send the range header...weird...

Seeking in HTTP files

Reply #7
yes -> i'm also looking forward to "http-seeking" mp3-files with foobar! winamp can do this already.

Seeking in HTTP files

Reply #8
Quote
Yeah its relative easy when you perform your HTTP Get request you use the 'Range:' header to request a sub-set of the whole content....


It doesn't appear this header is ever sent.

I've been playing around with this... and wrote a reader that provides the same responses as a local file would.  I (more or less) us the Range header.  It works.  But when seeking, Foobar starts over at the beginning, and reads quickly through the file (just as it would during normal playback... just faster).

While using the Range header works, it's horribly slow.  While files in MPC and Vorbis read larger blocks of data, MP3 reads these teeny-tiny blocks (lots of 4 byte and 414 byte blocks).

My reader actually "caches" the data to a local temp file, and on another thread reads ahead of the current position.  It works, but there are issues. 

However, there are some pleasing side-effects:

1) Foobar can't destinguish between my streaming reader and a local file, so I get all the tags.

2) The web server isn't transcoding.  It's simply serving up the actual track.

It's unclear whether I can support tag writing with this.  Haven't progressed that far.  At this point, this little project is just experimental.
Santa is very jolly because he knows where all the bad girls live.  - Dennis Miller

Seeking in HTTP files

Reply #9
Are there any issues with opening multiple files with your reader, or perhaps opening the same file multiple times?

You might want to consider a global cache container class that either stores each file in its own temp reader, or stores bits of each file in memory. It could either do the http reading itself, or tell the caller when the data is not available in the cache and allow the caller to pass it a chunk to cache. Designing the cache to do the reading would complicate support for multiple simultaneous connections to different servers, unless you delegate each connection to its own worker thread.

Whee. Good luck with your project.

Seeking in HTTP files

Reply #10
Right now, it handles just a single file because I'm trying to really understand how fb2k uses it.  There is a lot of room for improvement.  For example:

1) Caching.  Not just entire files, but "chunks" (like you mentioned).  i.e., If you listen to half a song, half the data could still be cached.

2) Some formats require a seek to the end, then back to the beginning.  Right now, that requires another request (with a Range)... the background thread will still end up reading it again.  Kinda wasteful...

3) It only reads the currently playing song.  If would be interesting to start scanning other files in the playlist while the first is still playing.  Not convinced how practical this is...  If I knew the next song to play... that would be interesting.

4) Since there is no cache, once playback stops, the local file is gone.  Obviously, a real cache would fix this.  But once the entire track is transferred, you can seek back and forth without delay.

Most of it won't be rocket science.  Chunk caching should be interesting; not as straight forward as file caching.  Should be fun...
Santa is very jolly because he knows where all the bad girls live.  - Dennis Miller

Seeking in HTTP files

Reply #11
By multiple file support, I did not mean precaching. I meant supporting multiple reader instances, and caching accordingly, or keeping older files in cache for just such an occasion. I know it probably won't see much use, but the core does support this, so you should code for it just in case.

Seeking in HTTP files

Reply #12
Quote
I meant supporting multiple reader instances, and caching accordingly, or keeping older files in cache for just such an occasion. I know it probably won't see much use, but the core does support this, so you should code for it just in case.


Thanks.  I didn't know that.  In what cases would multiple readers be created?  I've only ever seen one at a time created.  But for that matter, I can't think of a reason more than one of my readers couldn't be created.
Santa is very jolly because he knows where all the bad girls live.  - Dennis Miller

Seeking in HTTP files

Reply #13
Well, if someone is RG scanning or converting a file while another file is open, a new reader instance is created to access that file. Which reader it uses depends on the path. file:// is handled by the core's internal file reader service, but all http:// will go to your reader.

Hmm, now that I think about it, even scanning or converting a file which is already open will open a new reader. I guess global caching and reading would help with this.

Seeking in HTTP files

Reply #14
OK.  Tricky.  My original intent was to handle writes too (if possible).  Interesting dynamic but overcomable I would imagine.  But then again, Foobar will queue a write if the file is in use, yes?  How does that work?  i.e. Does Foobar keep track of what's in use, or does the reader fail in some way that triggers that?
Santa is very jolly because he knows where all the bad girls live.  - Dennis Miller

Seeking in HTTP files

Reply #15
Any progress with this?, have you got some code I can tinker with ?
Cheers

Seeking in HTTP files

Reply #16
Quote
Any progress with this?, have you got some code I can tinker with ?


I haven't had time to do much more than my original proof of concept.  I'd be glad to share the code.  It's important to note that as it exists now, it does not "talk" to any known streaming server (though improving fb2k streaming is still a goal of mine).  I wrote a little Java servlet to handle the server side.  Not sure if you're still interested, but if you are, send me a message (with an email address) and we can talk more.

Edit:  or if you prefer, I can post the code on a web server and e-mail you the link.
Santa is very jolly because he knows where all the bad girls live.  - Dennis Miller

Seeking in HTTP files

Reply #17
javajunky@wombatinvasion.com  Shouldn't be a problem, I'll be testing again WombatShare (http:\\www.wombatinvasion.com\) so I can control the server side stuff

Cheers dude.