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: Feature request: Seeking when playing remote content over HTTP (Read 904 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Feature request: Seeking when playing remote content over HTTP

Hello,
I have two remote libraries.

I access first one over FTPES. It's working fine including seeking. I guess FTP files are first downloaded into a local cache so they can be played. However by watching the console while indexing of that remote library is in progress I can see partial transfers are possible over FTP.

I access the second one as a webdav share over HTTPS. I have got nginx with its dav_ext extension at the server side. I can test with wget and curl that get requests do support  Content-Range headers.
Might it be possible to add seeking over http when playing content from a webdav remote library?

I do mainly have MP3, flac, matroska with multiple opus audio tracks, ogg opus and ogg vorbis files.

When testing with VLC media player on a linux desktop seeking is working with this web server.

Edit: On windows with Foobar 2000 v2.1, seeking is also possible when adding remote content through HTTP with Add location functionality.

This is a curl -I pointing to one of random MP3 files from that webdav share.
Code: [Select]
HTTP/2 200 
server: nginx
date: Thu, 04 Jan 2024 13:19:08 GMT
content-type: audio/mpeg
content-length: 12380131
last-modified: Wed, 07 Nov 2007 21:00:41 GMT
etag: "47322779-bce7e3"
accept-ranges: bytes

Re: Feature request: Seeking when playing remote content over HTTP

Reply #1 –
Hello,
I have finally figured out why I am the only one with this issue.
It turns out On android Foobar 2000 can seek in both local and remote MP3 files. But the files have to have id3 tags included. If the file has no tags such as recorded with an audio recorder app, it's not seekable. Can this be looked into please?

Re: Feature request: Seeking when playing remote content over HTTP

Reply #2 –
Hello again,
In order to try better explaining this request I have prepared a few test samples.
In the attached zip file there are 6 1 minute long sample files in total. Tree of them do contain meta data and are seekable when played with foobar 2000 mobile on android.
Other three are missing meta data and are not seekable when played with foobar 2000 mobile on android.
In fact it's the same sample converted to MP3, to opus and to ogg vorbis.
My original assumption was that the fact some of the files are not seekable when played with foobar 2000 mobile on android might have something to do with networking. It turned out I was wrong.

Greetings

Peter

Re: Feature request: Seeking when playing remote content over HTTP

Reply #3 –
Fixed in today's build, thanks for reporting.
This was fun, poor workarounds for different issues interacting badly with each other - specifically, hack not to overwrite UPnP sourced info with blank track info. I've rewritten offending parts, hopefully nothing else broke.
Microsoft Windows: We can't script here, this is bat country.

Re: Feature request: Seeking when playing remote content over HTTP

Reply #4 –
Hello and huge thanks for working on this.
It appears it's not yet fully resolved for me but it's very likely I haven't realized I have to include much more details.

I think I need to explain how I am using Foobar 2000 on mobile.

I'm blind thus I don't like skinned playback screen and I have turned it off in the advanced settings.
If I wish to seek I can either use the slider on the playback screen, slider that is a part of the notification visible on the lock screen or in the notification area or I can use mult imedia keys fast forward / rewind.
When I tap an item in the list of files in the media library, non skinned playback screen displays for me.
On android sliders are usually manipulated in a way so I have to touch the handle and while still touching the screen I have to drag it to the side. When so called explore by touch accessibility feature is turned on it's possible to adjust the slider by dragging the handle with two fingers but that is not very convenient and talkback and other 3rd party screen readers have implemented gestures for manipulating sliders. Thus when manipulating sliders I am relying on the screen reader functionality. With talkback that is touching the slider once then using volume keys to change the value.

Here are my observations:

MP3 file with tags present, MP3 file with tags missing, opus file with tags present and opus file with tags missing:
* Seeking the slider that is part of the notification is no longer working at all. I think it used to work in earlier versions but I don't know when it stopped working as I am not using it that often.
* Seeking with multimedia keys is working fine.
* Slider on the non skinned playback screen is greyed out (I can't move it) until I do the first attempt for seeking with the multimedia keys. So if there are no multimedia keys on the device I can't think of a way on how to initiate seeking.

Flac files with tags present, Ogg vorbis files with tags present and ogg vorbis files with tags missing:
* The behaviour is roughly the same but the initial attempt for seeking often starts playing from the begining of the track. Additional attempts for seeking are then working fine with the slider found on the non skinned playback screen and multimedia keys. Notification slider is not working with vorbis files either.
 

Re: Feature request: Seeking when playing remote content over HTTP

Reply #5 –
Hello,
Since my last report I have also noticed opus and matroska files start randomly playing from the start of a track when doing initial seek forward. So it appears to be the same thing I have reported for ogg vorbis and flac files yesterday.

Thanks and greetings

Peter