v0.7 stops after a few minutes

[pupvogel]

Hi,

my Mixcloud-Plugin v0.7 stops playback after several minutes, unfortunately without logging anything even in Debug-mode.

I have found other, old threads where this was mentioned and the solution was to reinstall the plugin, but unfortunately that doesn't help.

I installed a screen capture tool to find out where exactly the playback stops - it is NOT always at the same time for a given track, it seems to happen quite randomly.
Most tracks I tested stop after 5 to 15 minutes, but I found this track here always stopped after 2-3min, so maybe it's a good one to start looking for the problem... 8-p
mixcloud://johndigweed/transitions-with-john-digweed-and-denney/

Most tracks I tested are about 1h long, this one is 2h, but it's just a wild guess that this has anything to do with the problem...

I'm running the (currently) latest build of LMS8.3.0 on Win10

Oh and the displayed bitrate and format indicators change when playback stops, for instance a track that shows "320 kbps/70kbps, mp3/mp4 (mixcloud)" during playback would show "64k, mp4" and stop right then.

[richardhenwood]

hi @pupvogel,

I had a similar, but different (tracks stopped at ~20mins, predictably). I engaged in a thread here:
https://forums.slimdevices.com/showthread.php?88286-Mixcloud-plugin&p=1015711&highlight=#post1015711
which resulted in a working setup for me.

[pupvogel]

Hi @richardhenwood,
in that post you say you installed ffmpeg into the LMS docker image and then it worked...
Phew, can you help me translate how this could help me in a standard windows install of LMS ?
Would LMS even know if I install ffmpeg on the machine..?

[richardhenwood]

Hi @pupvogel

I don't have much experience with windows - sorry! I might expect that if ffmpeg was installed on the windows machine, LMS my test obvious places - or maybe just the path? - and do the right thing. This page talks about installing ffmpeg and path on windows: https://www.wikihow.com/Install-FFmpeg-on-Windows

[pupvogel]

Hi, unfortunately installing ffmepg didn't help.
I made sure it's available everywhere through the environment variable, but sadly problem remains the same.

[chieftobitobsn]

I have the sam eproblem on two different installations. Its installed on a raspi 3 with debian on it. Squeezebox Server is 8.2 and Mixcloud Plugin is 0.7.

Soundcloud Plugin is running without problems, but mixcloud is so much better.

does somebody know whats the problem?

[kwarklabs]

There isn't any code in the plugin that could cause a stream to stop once playing. If this is still a problem then raise an issue against the server repository. Suggest closing this issue.

[pupvogel]

Well, it's definitely still a problem that I only have in the Mixloud-plugin, I just re-tested the "Digweed Denney"-example I mentioned above. Track will stop after about 2min35.

Current version is latest LMS 8.3.0 on Windows 11.

Just turned all debug-logging on that seems to matter, but I just don't get anything useful there.

[kwarklabs]

You could try playing the mix without using the MixCloud plugin.

1. Download the mix using dlmixcloud.com.
2. Add the downloaded file to your music library and rescan.
3. Find the mix in you library and play it.

The stream you quoted is MP4 so there is a good chance that something needs configuring elsewhere in your server to enable MP4 playback for your client. See Advanced -> File Types in the server settings.

You may also find that PR #25 helps once merged as it has a fix for streams which disconnect (HTTP code 206).

[pupvogel]

I downloaded the track from dlmixcloud (nice page btw) - the downloaded file plays perfectly on my players without stopping.
Your HTTP code 206-fix sounds quite promising, though !? Is there a way for me to try it out ?

[kwarklabs]

@danielvijge merged our recent pull request for the SoundCloud plugin quite promptly so probably easiest just to wait for this pull request to be merged and released.

But if you really can't wait then backup the Plugin.pm, ProtocolHandler.pm and strings.txt files in your Mixcloud plugin folder (/var/lib/squeezeboxserver/cache/InstalledPlugins/Plugins/MixCloud) and replace them with the files from PR #25 then restart your Squeezebox server.

[richardhenwood]

@pupvogel did you update the file type within LMS to specify using ffmpeg?

[pupvogel]

@richardhenwood No I didn't, don't really know how exactly.
I just installed ffmpeg and made it available through environment path.

[pupvogel]

@kwarklabs I installed the 3 files into my server, unfortunately the changes in there don't fix this problem.
The mentioned "example-track" will still stop somewhere between 2min30 and 3min00.

[richardhenwood]

@pupvogel it is probably best to wait for the update from kwarklabs - or pull the latest version as they suggest. Also, the thread on forums.slimdevices.com is probably worth following too...

[kwarklabs]

@pupvogel suggest doing the following:

1. Enable debug logging for the following sources:
   (plugin.mixcloud) - Mixcloud
   (formats.audio) - File Metadata & Audio Parsing Information
   (formats.metadata) - Remote stream metadata information
   (player.streaming) - All Player Streaming Logging
   (player.source) - Player Source Audio & Conversion Logging
   (player.streaming.direct) - Player Direct Streaming Logging
   (player.streaming.remote) - Player Remote Streaming Logging
   (network.asynchttp) - Asynchronous Remote HTTP Request Information

2. Stop the Squeezebox server and delete the server.log.

3. Start Squeezebox server and play the problem stream until it stops.

4. Post the server.log file here.

5. Post your convert.conf and custom-convert.conf files here (should be in Squeezebox server base folder on Windows).

[pupvogel]

Ok, I attached those 3 files in mix.zip.
I had no custom-convert.conf-file in the server base folder, I found one in .\Slim\Plugin\NetTest though.....guess that file isn't really relevant.

mix.zip

Thanks for looking into this !!

[kwarklabs]

@pupvogel There's something not right about the way your server is transcoding the stream.

Lines 597 through to 617 of your server.log describe the process of matching the stream to the rules in your convert.conf.

At the end of the process is the error line:
Slim::Player::TranscodingHelper::getConvertCommand2 (490) Error: Didn't find any command matches for type: mp4

It then matches the stream to the convert.conf line which is supposed to be for converting from AAC to FLAC.

On our test server the convert.conf rule which matches converts from MP4 to AAC as follows:
Slim::Player::TranscodingHelper::checkBin (268) Checking formats for: mp4-aac--
Slim::Player::TranscodingHelper::enabledFormat (235) Checking to see if mp4-aac-- is enabled
Slim::Player::TranscodingHelper::checkBin (276) enabled
Slim::Player::TranscodingHelper::checkBin (278) Found command: -
Slim::Player::TranscodingHelper::getConvertCommand2 (493) Matched: mp4->aac via: -
Slim::Player::Song::open (416) Transcoder: streamMode=I, streamformat=aac

MP4 is a container file type which in this instance contains audio encoded with the AAC codec and is native in SqueezeBox server.

On your server the faad command is transcoding the stream, which it can do when the correct command line is used. However it seems that because the convert.conf line being matched isn't the correct one it's not playing to the end. On top of that it seems to be converting from native AAC in to FLAC and then using flac.exe, presumably to convert it back in to a native format.

Your convert.conf file is the same as the one distributed with the latest server release so the problem must be caused by something else in the config.

In the server settings under Advanced -> File Types, do you have any "Disabled Audio File Extensions" or "Disabled Playlist File Extensions" listed? On our test server there are none in either box. In the same screen is the "File Format Conversion Setup" "Prefer native format (decoding on the player) whenever possible" box ticked? On our test server it is ticked.

Then in the server settings Advanced -> Network screen what setting do you have for "Steaming mode for HTTP(S)"? On our test server we have "Normal Streaming" selected.

Finally, what is the player you are trying to stream to and what version of software/firmware is it running? You can view this information on the server in the Settings -> Information tab. We've tested with SqueezePlay (8.0.1-r1382) and Squeezelite (v1.9.9-1392) players.

[pupvogel]

Hi,
it looks like I have the exact same settings, see screenshots.
Issue occurs on all my players: Squeezelite-X, Boom and Classic v2.
So is there a way to make it use the right converter..?

[pupvogel]

...since today, when I start to stream, a shell window opens with text running through.
That window closes after a minute or so, while the music keeps on playing until about 2min35.

First I thought this is an unwanted effect of the new build I installed this morning, but it looks like this happens because I set some logging values to debug, is that possible...?
Maybe this info helps, I copied the text shortly before that window closes.

My feeling is, the stream is downloaded for the first approximately 2min35, and then those "watchdog processes" just switch off after nothing is downloaded for another 15 seconds, even though they should wait longer........since I'm still streaming.....

watchdog.txt
.

[kwarklabs]

I'm sure someone will correct us if we're wrong but we don't think AAC can be played natively on Windows players or these older legacy hardware players. And in that case, the convert.conf line matched is correct, the transcoding you are seeing is expected behaviour and is unavoidable without switching operating system/hardware.

Turning on (player.source) debug logging is causing the cmd window you mentioned to open.

The watchdog.txt logfile you attached is from SocketWrapper which is a process that can be seen in your server.log as part of transcoding.

If you look in the forums you will see there that quite a few other users are reporting problems with symptoms like yours associated with SocketWrapper. Example threads here:
https://forums.slimdevices.com/showthread.php?114661-Music-streaming-stops-intermittently
https://forums.slimdevices.com/showthread.php?116078-Spotty-and-socketwrapper-1-12beta

Suggest subscribing to these threads and following progress there.

[kwarklabs]

@chieftobitobsn have you seen any change since updating to Mixcloud plugin v0.8 which was released yesterday?

If not then suggest doing the following:

1. Enable debug logging for the following sources:
   (plugin.mixcloud) - Mixcloud
   (formats.audio) - File Metadata & Audio Parsing Information
   (formats.metadata) - Remote stream metadata information
   (player.streaming) - All Player Streaming Logging
   (player.source) - Player Source Audio & Conversion Logging
   (player.streaming.direct) - Player Direct Streaming Logging
   (player.streaming.remote) - Player Remote Streaming Logging
   (network.asynchttp) - Asynchronous Remote HTTP Request Information

2. Stop the Squeezebox server and delete the server.log.

3. Start Squeezebox server and play the problem stream until it stops.

4. Post the server.log file here.

5. Post your convert.conf and custom-convert.conf files here (should be in /etc/squeezeboxserver on Debian).

[pupvogel]

Just checked with new v0.9, same problem. 8-(

[kwarklabs]

@pupvogel The github repository that includes SocketWrapper and where you can raise your issue is here:
https://github.com/Logitech/slimserver-tools

The Pull Request where the issue is being discussed is here:
LMS-Community/slimserver-tools#3

And a beta test version of SocketWrapper.exe is here:
https://sourceforge.net/projects/lmsclients/files/utility/socketwrapper-1.12beta.zip/download

@chieftobitobsn said they are running Linux, so not using SocketWrapper.exe.

[kwarklabs]

@chieftobitobsn reported problems resolved here #27 so closing.

[pupvogel]

Hi,

@kwarklabs I still have this problem, so why close my thread for this !?

bpa over in this thread can't (yet) pinpoint where the problem is coming from.

So the problem could be in "new" parts of LMS such as MPEG4 handling and LMS buffer/persistent HTTP, mixcloud MPEG4 handling (it has copied some of LMS code) or socketwrapper.

I think we can rule-out socketwrapper, because I have the same issue on hardware players that use socketwrapper, but also on Squeezelite-X, which doesn't seem to use socketwrapper at all.

[kwarklabs]

@pupvogel Sorry that your problem is not yet resolved but there is no code in the mixcloud plugin that could be causing this.

The plugin passes a URL for the file to be streamed to the server. The server then streams and transcodes as required.

You are seeing the issue on both your hardware and squeezelite-x players because they both need the AAC stream to be transcoded and handle the stream in the same way.

The soundcloud plugin works for you because it only streams MP3 files.

Others are reporting the same issue using the Spotify plugin which also streams AAC format as documented here:
https://support.spotify.com/us/article/audio-quality/

If we want this to be resolved then we need to contribute to the github repository that hosts the code that has the problem.

[kwarklabs]

@pupvogel see slimserver pull request LMS-Community/slimserver#786

[pupvogel]

now that sounds quite promising, thanks!!