FLAC tracks stop playing 1 min from end

[gcgst]

I am using DSub to Chromecast FLAC's (transcoded to either MP3 or WAV - tried both), and the tracks will play fine up to 60 seconds before the end of the track, and then it skips to the next track. I only seems to happen with the Chromecast/FLAC combo. I can Chromecast MP3's fine.

I can manually run ffmpeg and the transcoded wav or mp3 is complete.

I emailed the DSub author, and he doesn't think it is his app's issue.

I have 1 week left on my eval period for subsonic server. Is there some cripple feature during eval period ? Has anyone else seen this? I would like to get this resolved before I buy a license.

Version 4.9 (build 3853) – January 23, 2014
Server jetty-6.1.x, java 1.7.0_55, Windows 8 (73.1 MB / 126.8 MB)

[GJ51]

Flac transcoding is tricky - especially if you get into the 24 bit variety.

Try this

viewtopic.php?f=4&t=14407&start=60

Set up separate 2 stage transcode just for flac

Remember to remove flac from the default transcode and check that the player you test it on has been enabled to use it.

HTH

[gcgst]

Thanks Gary. Tried the two-stage transcode, but it didn't help.

The subsonic status page indicates the entire file is streamed (based on size in MB).

The same Flac file can be Chromecast without issues using BubbleuPnP -- but I am not sure what transcoding it is doing.

[gcgst]

Another data point. If I setup BubbleUPnP to use subsonic DLNA server, I see the same problem. The log indicates input stream is getting cut short (?)

[2014-06-17 08:27:49,157] DEBUG InputStreamReaderThread - (c:\subsonic\transcode\flac) Eagles-Wasted Time (reprise).flac: 7% complete
[2014-06-17 08:27:49,157] DEBUG InputStreamReaderThread - (c:\subsonic\transcode\flac) Eagles-Wasted Time (reprise).flac: 14% complete
[2014-06-17 08:27:49,157] DEBUG InputStreamReaderThread - (c:\subsonic\transcode\flac) Eagles-Wasted Time (reprise).flac: 21% complete
[2014-06-17 08:27:49,157] DEBUG InputStreamReaderThread - (c:\subsonic\transcode\flac) Eagles-Wasted Time (reprise).flac: 28% complete
[2014-06-17 08:27:49,157] DEBUG InputStreamReaderThread - (c:\subsonic\transcode\flac) Eagles-Wasted Time (reprise).flac: 36% complete
[2014-06-17 08:27:49,157] DEBUG InputStreamReaderThread - (c:\subsonic\transcode\flac) Eagles-Wasted Time (reprise).flac: 40% complete
[2014-06-17 08:27:49,157] DEBUG InputStreamReaderThread - (c:\subsonic\transcode\flac) Eagles-Wasted Time (reprise).flac: done

It always gets to 40% and then reports done.

[GJ51]

I've seen suggestions recently that it may be related to the current version of ffmpeg being used.

Try upgrading ffmpeg to the latest release.

viewtopic.php?f=4&t=14407&start=60

Read this post.

New releases of ffmpeg:

http://www.ffmpeg.org/download.html

HTH

[gcgst]

I have upgraded ffmpeg to latest. Still the same issue.

However, I did find a way to make it work on a test file.

I edited a Flac file using a hex editor and padded the end of the file with nulls (0x00) until its file size matched the size of the wav file it would produce if decoded. The flac file then played to completion via Chromecast.

Thus, it appears the subsonic is incorrectly using the file size of the Flac file to determine how much to stream to the transcoder(s) ?

[gcgst]

I filed bug #121 for this.

I downloaded the subsonic source and was able to fix it myself. The original code set the "Content Length" and "Content Range" based on file size if it couldn't figure it out any other way. I added a test for flac format and calculated content length based on flac metadata - bits-per-sample, number of channels, total samples plus wav header. Chromecast is now happy and I don't have to use any lossy compression to playback flac files.

[maverickagm]

Cool. I had posted a message on that bug stating that I had the same problem. I also included a stack trace that was left in my subsonic log when sending a flac > wav stream to chromecast. My message is still pending moderation though. Would you be able to post your code change? I wouldn't mind building the subsonic server from source to get this fixed.

[gcgst]

I added jFLAC library for the metadata read -- as the API in jAudiotagger was not really documented, and I couldn't figure it out. This is a quick hack of StreamController.java, but it works:

52,53d52
<
< import java.io.FileInputStream;
55d53
< import java.io.InputStream;
61,63d58
< import org.kc7bfi.jflac.FLACDecoder;
< import org.kc7bfi.jflac.metadata.StreamInfo;
<
90d84
< long contentLength = 0;
131,158d124
< LOG.info("In handleRequest = encoding type = " + file.getFormat());
< if (file.getFormat().contentEquals("flac")) {
< /* TODO switch to jAudioTagger once figured out how to use their metadata class */
< LOG.info("In handleRequest ###### FLAC #######");
<
< InputStream is = new FileInputStream(file.getFile());
< if (is != null) {
< FLACDecoder fdec = new FLACDecoder(is);
< if (fdec != null) {
< fdec.readMetadata();
< StreamInfo streaminf = fdec.getStreamInfo();
< if (streaminf != null) {
< int bps = streaminf.getBitsPerSample();
< int num_chan = streaminf.getChannels();
< long tot_sample = streaminf.getTotalSamples();
< contentLength = ((bps * num_chan * tot_sample) /8) + 44;
< } else {
< LOG.info("In handleRequest Could not get StreamInfo for file " + file.getFile().getAbsolutePath());
< }
< } else {
< LOG.info("In handleRequest Could not create FLACDecoder");
< }
< } else {
< LOG.info("In handleRequest Could not open input stream for file " + file.getFile().getAbsolutePath());
< }
<
< LOG.info("In handleRequest FLAC contentLength = " + contentLength);
< }
170c135
< long fileLength = (contentLength > 0 ? contentLength : getFileLength(parameters));
---
> long fileLength = getFileLength(parameters);