Serviio

Hi
I am still struggling with streaming to my Revo AXIS.

I have set up a Revo transcoding profile in profiles.xml which looks like this:



The profile loads fine and I can attribute it to the Revo in serviio console.

When I stream 44.1kHz or 48kHz samplerate FLAC files, everything works fine. They get sent to the Revo AXIS as 44.1 and 48kHz LPCM and they play.
When I stream >48kHz FLAC files (88.2, 96 and higher), the Revo respons with infinite "reconnecting".

If I change the "lpcm" target container to "mp3", I can stream everything up to 192kHz sample rate. It gets converted to 192kps MP3 and plays fine.

It looks like there is something different in an lpcm stream which is "native" / unconverted and one that is transcoded / downsampled to 48kHz LPCM.

It would be great to be able to stream lossless hirez files as lossless LPCM.
Thanks a lot for looking into this.

can you post detailed log of playing the file, especially the ffmpeg command used to transcode?

I have attached two detailed logs in one zip file:
- transcoding to mp3 for a 44.1kHz FLAC file(works) and a 192kHz FLAC file (works)
- transcoding to lpcm for a 44.1kHz FLAC file (works) and a 192kHz FLAC file (doesn't work, keeps reconnecting)

This is the lpcm command (didn't see he other one in the log)



Is it the 196 of 44.1 file?

Hi Petr,
I have done another transcoding run, this time only with a 24bit/192kHz FLAC file. I tried to play two different files. The log is attached.
Interesting result. There is NO log entry for FFMPEG running to transcode the file. Same as in the last log where you could not find an FFMPEG entry for the 192kHz file.

So it seems to me that:
- with transcoding to MP3, both the 44.1kHz and the 192kHz FLAC file get transcoded
- with transcoding to LPCM, only the 44.1kHz FLAC file gets transcoded, the 192kHz file has no FFMPEG entry in the log
That would explain, why I keep getting a "reconnecting" error with the 192kHz FLAC file. Somewhere there seems to be an error in the script logic.

Something else is not quite right in the mp3 transcoding. The transcoded mp3 file streams to the Revo AXIS and plays ok, but it shows a total tracklength of 6h14'30". After the track finishes at around 7'30", I get the "reconnecting" error message.

Two more suggestions:
Since FFMPEG 1.1 it is possible to use the SOX resampler with FFMPEG https://trac.ffmpeg.org/wiki/FFmpeg%20and%20the%20SoX%20Resampler. SOX has a much better resampling quality than the native FFMPEG resampler. Have you thought about using SOX?
Somewhere in your script you use a logic to determine whether the samplerate of the transcoded lpcm file is 44.1kHz or 48kHz (samplerate, not bitrate). With a 44.1kHz file it will output a 44.1kHz LPCM file, with a samplerate of 48kHz or greater, it will output a 48kHz LPCM file. Would it be possible to adapt this logic to resample as follows:
44.1 / 88.2 / 176.4 / 352.8kHz -> 44.1kHz
48 / 96 / 192 / 384kHz -> 48kHz
If this could be done, it would resolve my feature request #831 on bitbucket.
https://bitbucket.org/xnejp03/serviio/issue/831/resampling-of-lossless-audio-files

Thanks a lot
Rudi

What is the file you're trying to play?

I have verified that I get the same error with the test files hosted on the first of the following two url's. I assume the files on the second url show the error as well.
http://www.2l.no/hires/
http://www.naimlabel.com/musicstore-test-files.aspx

I have noted the same behaviour as I have reported in my previous post

Transcoding to mp3 works with all files BUT the duration of the file is indicated way too high (10hours +), which leads to a "reconnecting" error when the file is done playing (way earlier than 10hours +)
Transcoding to lpcm works with 44.1kHz FLAC files, but the duration of the file is indicated too high (1hour +)
Transcoding to lpcm does NOT work for 96kHz and 192kHz FLAc files

I hope that you will be able to reproduce the error troubleshoot the issue using the demo files on the two sites

Right, so the fact it's not in the log is that DLNA doesn't support anything above 48k sample rate, so Serviio doesn't even try to transcode it and serves it as flac.

Try to change your profile to



That would resample it to 48k, but will probably screw up your other files, which will play 'faster'.

In any way, to do it properly, and still be within the DLNA standard, I could resample 192 to 48 - as you suggested above. is that something you guys (audiophiles) would be interested iun, to play the file even if it means losing some of the sampling detail?

EDIT: actually there is already a similar ticket: https://bitbucket.org/xnejp03/serviio/i ... udio-files I think your solution is similar and requires simpler profile transcoding rules, ie anything other than 44.1 and 48 will be resampled to one of these two automatically.

Ticket #831 on Bitbucket was actually posted by me, so it's basically the same issue.

I have been an audiophile for many years and making streaming work between different devices of different capabilities has been a major issue all the time.
In my view the "clean" solution in this case would be:
- to have the possibility to stream "as is", i.e. with the original sample rate, even if that does not conform exactly to the DLNA standard. Most other DLNA servers do that (the Synology Media Server for sure).
- if "transcoding" is selected then the downsampling should be to either 16bit/48kHz or to 16bit/44.1kHz, depending on the incoming samplerate. Defining the transcoding rule for incoming samplerates up to 705.6kHz (=16*44.1) and 786kHz (=16*48) should be sufficient for the foreseeable future.

Serviio would be the first DLNA server to offer a clean solution for this issue. All others resample all rates to either to 44.1 or 48.

Are there other views on this?

Petr,
One more thing.
Have you been able to look at the issue that transcoding to mp3 actually DOES work for incoming samplerates > 48kHz, but the duration of the resulting mp3 file is way to long, leading to problems when the track finishes playing?

Petr,



I have modified my profiles.xml entry in this way. Now the 96kHz and 192kHz files are transcoded and DO play as 48kHz LPCM.
However all transcoded files (192, 96 and 44.1kHz) show a total duration of 1:18:07 instead of 9:14
They play at the correct speed.

I then manually created a transcoded 48kHz file from the 192kHz file, using the following mpeg command:

The resulting 2.wav file plays ok when streamed from Synology Media Server and it displays the correct duration on the Revo AXIS.

That's due to the player ignoring the duration Serviio sends and working it out by the file size. As the file is transcoded, Serviio doesn't know the future file size and sends a fake large number, which the player interprets as what you're seeing.

I am getting the same issue (although with different crazy long durations for the same file) when streaming from Synology Media Server with transcoding turned on (both on the Revo AXIS and on jRiver as renderers).

Is this a problem
- with the renderer (Revo AXIS or jRiver)?
- with the DLNA Standard?
- that can be fixed within Serviio?

If it is a Revo AXIS renderer issue, I will report it to Revo.
BTW, I am getting an error message when I try to load Serviio as a DLNA server in jRiver



so I cannot check whether this also happens when using jRiver as a renderer for Serviio.
I also get crazy durations when using my Oppo BDP-83 as a renderer.