Hi - I've upgraded to 1.4.3 from 1.3.x and that causes some of my other apps to fail. More precisely, what happens is that when f2k opens an HTTP url for playback, it opens a first socket, does a GET, opens a second socket, does the same GET and then closes the 1st socket. That creates problems with URL where the content is not a fixed ressource (streaming / consumable) and it causes playback to fail as headers are gone (consumed) byt the first socket. Is there a specific reason for that key behavior change?
Thanks
BTW, I'm not saying that expecting the 2 GET requests on the same resource to return the same (or a streamable content, i.e. bound to a packet) is a wrong assessment, but it's a strong assessment that maybe does not need to be done. If the objective is to get the headers at first, with not making a HEAD request instead?
Here is a small example
12:29:23 192.168.2.10:11934 Connected
12:29:23 192.168.2.10:11934 Requested GET /BL16-44-flac.flac
12:29:23 192.168.2.10:11934 Request dump
> GET /BL16-44-flac.flac HTTP/1.1
> Host: 192.168.2.10:8080
> Connection: close
> User-Agent: foobar2000/1.4.3
> Accept: */*
> Icy-MetaData:1
12:29:23 192.168.2.10:11934 Sent 1460 bytes
12:29:23 192.168.2.10:11935 Connected
12:29:23 192.168.2.10:11935 Requested GET /BL16-44-flac.flac
12:29:23 192.168.2.10:11935 Request dump
> GET /BL16-44-flac.flac HTTP/1.1
> Host: 192.168.2.10:8080
> Connection: close
> User-Agent: foobar2000/1.4.3
> Accept: */*
> Icy-MetaData:1
12:29:23 192.168.2.10:11935 Sent 1460 bytes
12:29:23 192.168.2.10:11934 Disconnected - 48180 bytes sent
12:29:27 192.168.2.10:11935 Sent 598600 bytes
12:29:27 192.168.2.10:11935 Served 1021.0 K
12:29:27 192.168.2.10:11935 Fully downloaded - 1021.0 K @ 325.5 KB/s - /BL16-44-flac.flac
12:29:27 192.168.2.10:11935 Disconnected by server - 1045508 bytes sent
The objective is to make sure that the operation returns consistent data, and not a dynamically generated stream that changes. Or at least, I think that's the reason.
Noted, thanks for reporting.
The objective is to make sure that the operation returns consistent data, and not a dynamically generated stream that changes. Or at least, I think that's the reason.
The objective is to make sure that the operation returns consistent data, and not a dynamically generated stream that changes. Or at least, I think that's the reason.
I understand but precisely the content is changing and the 2nd GET fails because of lack of headers. Maybe it would be more robust then to scan for sync pattern on streamable streams. Again, I agree that the behavior of my application is questionnable and I've added a workaround but it might also be better for fb2k to not make these assumptions (don't know why I wrote assessments ...)
Noted, thanks for reporting.
YW - Thanks for making f2k, it has been extremely useful to me in my developments
Temporary workaround:
Open Preferences / Advanced / Playback / Buffering
Set read-ahead for remote files to zero
This should prevent the unwanted behavior.
Turns out this doesn't help.
I'm working on a better solution for the next foobar2000 update.
Temporary workaround:
Open Preferences / Advanced / Playback / Buffering
Set read-ahead for remote files to zero
This should prevent the unwanted behavior.
I'm working on a better solution for the next foobar2000 update.
Thanks. I've tried and it seems that the same behavior still happens
20:59:37 192.168.2.10:7452 Connected
20:59:37 192.168.2.10:7452 Requested GET /BL16-44-flac.flac
20:59:37 192.168.2.10:7452 Request dump
> GET /BL16-44-flac.flac HTTP/1.1
> Host: 192.168.2.10:8080
> Connection: close
> User-Agent: foobar2000/1.4.3
> Accept: */*
> Icy-MetaData:1
20:59:37 192.168.2.10:7452 Sent 1460 bytes
20:59:37 192.168.2.10:7453 Connected
20:59:37 192.168.2.10:7453 Requested GET /BL16-44-flac.flac
20:59:37 192.168.2.10:7453 Request dump
> GET /BL16-44-flac.flac HTTP/1.1
> Host: 192.168.2.10:8080
> Connection: close
> User-Agent: foobar2000/1.4.3
> Accept: */*
> Icy-MetaData:1
20:59:37 192.168.2.10:7453 Sent 1460 bytes
20:59:37 192.168.2.10:7452 Disconnected - 48180 bytes sent
20:59:38 192.168.2.10:7453 Sent 147460 bytes
20:59:39 192.168.2.10:7453 Sent 94900 bytes
20:59:40 192.168.2.10:7453 Sent 32120 bytes
20:59:41 192.168.2.10:7453 Disconnected - 293460 bytes sent
Indeed, removing buffering alone doesn't fix it, corrected information in the previous post now.
A proper fix will be included with foobar2000 v1.4.4 soon.
Happy to report that it works on beta 1.4.4
Thanks!