I have trouble streaming/playing tunes with foobar2000 v0.9 in Jinzora, when trying i get errors like:

Unable to open item for playback (Unsupported format or corrupted file):
"http://www.jinzora.org/demos/standalone/mediabroadcast.php?resu_zj=3321aa1344624RSU&dis=ab125f0330244S&htap_zj=63892a4654624T&noitca=yalp&epyt=kcart&ext=.mp3"

Please test if this is reproducable on:
http://www.jinzora.org/demos/standalone/slick.php

PS. This error does not come up with version 0.8.3 of foobar2000

/androb

Their server software should not be returning content-length for dynamically-generated content, otherwise we open the file as seekable and things break when the file is modified apparently while we're reading it. Not a bug.

Hi,

I get the same error with Foobar 0.9.



I also have a problem with playing playlists generated with Netjuke. There I don't get the same error, the files load nicely and start play, but then Foobar skips to the next track within a second or two. This didn't happen with 0.8.3

http://www.hydrogenaudio.org/forums/index....=0&#entry380313.

Although it is not a bug, could there be some workaround?

Rgds,

.brum

moderation: Added [ codebox ] to keep forum layout from breaking.

I think there should be SOME kind of workaround or plan for supporting it when the same problem happens with netjuke, jinzora, and anapod xtreamer.

foobar 0.9 streams just fine off whatever device is running the server as long as the address starts with 127.0.0.1- if you try to stream from a different device, you get the unsupported format or corrupted file error. 0.8.3 never had any problems streaming, it just wouldnt show up as seekable. and to tell you the truth i dont CARE at this point if the end result is seekable and the id3-info gets read. if the player has that much of a problem reading the streaming info, it should automatically switch back to the 0.8.3 protocol.

It's probably true that they shouldn't send that header, but I think it would be much better to implement something that works "in the wild". The suggestion to fall back to 0.8.3 behavior if things break is a good one, IMO. Can this be done?

Thanks
calle

[deleted by stephen as being absolute rubbish]

I not think it is a bug from jinzora. The files which got send are regular MP3 files. One URL per file and all are organized in a playlist which foobar plays. So they really have a length! And in 0.9 Beta 10 it is even seekable by foobar2000!

The problem is the new http-reader. For me it is very bad taste that discussion like this or disk fragmentation issues are just seen as bugs from jinzora or from the operating system (HT) ...

I always liked foobar2000 because it was a simple and reliable tool. Done by developers who really now what they do. foobar2000 is still the best MP3 player I ever used but those issues should not be seen as just some users do critizise but taken seriously.

Better maybe think about the many new features of foobar and get a little back to the roots. With less bugs.

Peter replaced a number of (third-party) libraries with new implementions because the old versions did not meet the new design goals; for example being able to cancel just about any operation instead of blocking the player while waiting for a time-out. So simply re-adding the HTTP code from 0.8.3 is not an option. However, new non-trivial code is rarely free from problems, so it might take some iterations for the current code to mature. (Lots of users only started using 0.9 after the beta cycle was finished.)

Hi,

I am one of the two main developers of Jinzora. Like osiris said, we do send the content-length because we know the length of the file. Ross coded up the HTTP bit so that files would be seekable in winamp and hopefully in other players too. I don't think this is a bug on our part.

But if we need to, we can add some user-agent checking to not send that header to foobar. What do you think?

While sending the current server time instead of the file date/time for static files may be a problem, there is still a problem with seeking around if we ignore the timestamp.

From lib/general.lib.php:

It looks like it will skip right over $skipBytes if it isn't an exact multiple of 1024 bytes. That really should be checking if $skipBytes - $i is less than 1024:
And since that loop appears twice, both instances will need to be changed.

And maybe getSkipBytes() in mediabroadcast.php could be checking to see if the range header really does begin with "bytes=", and whether or not there is any whitespace around the equal sign. Or is the httpd supposed to be simplifying this?

Hey kode,

Thanks for the fixes, I've updated our code in CVS (we should have a release coming out soon as well). I improved the parsing for skipBytes and replaced those for loops with a quick fseek() call. My last concern is whether or not a player would ever request only a middle part of the file? Do we have to worry about other formats of the HTTP_RANGE header?

I just tried foobar 0.9.2 final with jinzora CVS.

The good thing is it really works! Even after the system going to standby and than back on the music continues correctly. The same with seeking.

I only sometimes get an error message on the first song when added to a play list that the time stamp changed. Than foobar continues with the second song correctly.

Does jinzora still change time stamps?

In general my impression is very good. http streaming with 0.9.2 and the latest jinzora seems much quicker. The song starts immediately and not after 2-3 seconds like with 0.9 Beta 10 and previous versions.

So I understand it right it is more or less a jinzora problem not a foobar problem? But why it worked in previous versions of foobar?

Whoops, I had a bug in the timestamping bit. I'll fix it in CVS right now. The line is in lib/general.lib.php on line 769:

header("Last-Modified: ".gmdate("D, d M Y H:i:s")." GMT", filemtime($path));

should be:

header("Last-Modified: ".gmdate("D, d M Y H:i:s", filemtime($path))." GMT");

If that still doesn't work, try:
header("Last-Modified: ".gmdate("D, d M Y H:i:s")." GMT");

Also, I'm not sure if resampling will work with Foobar right now. If you try it, let us know how it goes...

I just upgraded jinzora via CVS.

And yes now it works perfectly!

Skipping to the next song in a playlist generated in jinzora and played in foobar (http) is now instantly and no delay at all.

Pressing Play in jinzora until foobar2000 starts playing the playlist is instantly. It only takes several milliseconds. It is really amazing.

http seeking works also quite quickly.

Resampling I never used.

Thanks a lot!

Very happy to hear it Thanks for sticking with us and helping test this out