Subsonic Forum

I'm finally posting here because I've tried so hard to get this working reliably over the past year and it just will not work as expected.

I have streaming working under perfect data conditions (ie wifi). I can stream my FLAC collection to my android and save files preserving gapless tracks! Woohoo awesome, thanks Sindre!

The issue is when I'm on 3g/edge. Almost every time I try to download a song not on wifi, the connection gets interrupted at some point. This is fine and expected on a mobile device and for transcoding to mp3 the stream recovers perfectly. For ogg, its a different story. The stream seems to recover (the download shows progress) but when trying to playback the track at some point it throws: Error Playing "songname". MediaPlayer error:-131 (0) (Exception)

I think this is a generic code for "the stream is effed up and I can't play it"

These are the transcoding configurations, both work as described above but have the same problem mentioned:

Single stage (FLAC>OGG):
1: oggenc -q 7 %s -o - (this preserves tags, WOW!)

Dual stage method (FLAC>OGG):
1: ffmpeg -i %s -f wav -
2: oggenc -q 7 -t %t -a %a -l %l -

I'm running on Linux (Debian Lenny, with latest subsonic 4.2) No special stuff here, plain install. Client is a Nexus One running latest available client from market.

Anyone can replicate this by simply using the transcoding settings above for their Android device, start streaming something over wifi, turn off wifi, then turn wifi back on. This will cause a data interruption and will show the woes of ogg streaming I've had the last year with subsonic.

The bug is particularly annoying because subsonic saves the file to the android device as if it was successful, so unless you go back and manually delete the file, you'll have a busted version of that song forever.

I think there is something wrong with the data stream resume on the client side. I'd really appreciate some advice here and especially someone to repro this to make sure I'm not crazy. Sindre, can you confirm this configuration works? Seriously, this the only way to get decent quality music on your android device while preserving gapless tracks... period.

Why is no one else complaining about this?

bump. Anyone else seen flac>ogg transcoding to be unreliable with intermittent data connectivity?

Yeah, I've had some issues with what seems like corrupted files. Also, I've yet to get flac transcoded to ogg with tags preserved. I've used all 3 of the ones you mentioned above.

make sure your flac files are tagged properly to begin with. I had to retag a bunch of stuff using media monkey/winamp to get it all working. Keep at it.

I was hoping Sindre would take a look at this streaming problem with ogg since he's been so diligent about maintaining the Android app. Apparently getting album art working consistently is more important than smooth audio playback currently

I still can't get flac -> ogg or native off to stream to anything. I tried your recipes and I get nothing.

You need to search Stozher's posts. He's the man when it comes to transcoding.

I have exactely the same problems as papatel.

Whenever the internet connection on the phone is interrupted I end up with a corrupted OGG file, regardless of the transcoding settings of subsonic.

It would be really great if someone (especially a developer) could acknowledge this problem. It should not disappear in the depths of this forum.

The thing is: it is not a transcoding problem per se. Transcoding to OGG is working beautifully and if the phone is connected through wifi or has a steady connection through 3G or whatever, I have a fully working OGG file.

The mentioned problem only occurs when the phone loses its connection while it is downloading the file. It will go on downloading as soon as it has a connection again but the resulting file will be corrupt and unplayable from a certain point forward.

If it helps I could provide an example file where this happened.

That's a problem that I'm pretty sure only Sindre can address. He would need you to send an example phone log that contains the error information. As someone who is unfamiliar with OGG, can I ask why you would use it on the Android as opposed to just transcoding to mp3?

In my transcoding settings, there's an entry ogg>mp3 with

Step 1: ffmpeg -i %s -f wav -

Step 2: lame -b %b - -

I've determined through double blind testing that I can reach near transparency with OGG at 64 kbit/s. With MP3 I would need at least double that. And because my data plan is capped at 300 mb I want to save as much bandwidth as I can.

So how would I go about getting said phone log?

I use an app called "Log Collector".

I got all excited today when I saw the android app update note: "Support for native OGG streaming" I have no idea what this means but it did not fix the above mentioned issue. Same exact behavior. Ogg stream is not able to recover if data connection is lost even momentarily. I tried all the transcoding methods possible for ogg I could think of and no luck.

If someone can guide me how to collect the client (android side) log, I can dump it here. I'd rather just have Sindre take 10 minutes of his time and take a look at this. The repro is sooo simple. He'll probably root cause in minutes and propose some solutions. Looks like he's at least thinking about it after the android app update note.

Please stop asking why we want to stream ogg. If you are happy with your mp3 format, stay that way. Some of us have tasted the benefits of ogg and can never go back.

Well, excuse us for trying to expand our knowledge while we try to help solve your problem.

If it says the player supports native streaming, then there is no transcoding needed. Just go into the settings for the player and unchek the box that defines the transcoding for the Android player and the ogg file will just pass through without any transcoding. Performance will improve and CPU load at the server will drop to next to nothing.

Please stop asking me how to fix ogg streaming. If you're not happy with it, don't stay that way. Some of us don't have the hassles you do and don't want to. Our servers work and we can never go back.