BBC Radio Stations crash mopidy

[jackrichardson]

After listening to any BBC radio station (e.g. BBC Radio 4) through TuneIn (on pimusicbox) for about an hour, mopidy crashes. There problem is only with BBC stations, as others work indefinitely.
I would give you a logfile, but I still don't quite know how to do that!

[kingosticks]

When you say "mopidy crashes", what exactly do you observe? I think pimusicbox has a monitoring mechanism that restarts Mopidy if certain conditions are met but I don't know what exactly triggers it.

I was just trying to reproduce it on my raspbian system and my ubuntu desktop. As soon as I start playing BBC R4 (arghhh, The Archers!) all MPD current playlist commands will then timeout except for status. Mopidy is still fully responsive and controllable using a web client. Changing to play a Spotify track or another Tunein station such as BBC R2 and full MPD control returned. There are no hints in the verbose log and nothing springs to mind. Pretty weird.

EDIT:
OK, I think I'm beginning to make some sense of this. Playing stations from the search results causes the MPD command timeouts. But playing the same stations from the browse results is fine. Maybe you can confirm this is the case for you too @jackrichardson? I'm very surprised this wasn't noticed before, maybe TuneIn have changed something on their end (or maybe my code is just bad).

[kingosticks]

I'm currently hitting this traceback http://dpaste.com/06FGYF1 when adding the search results to the tracklist. Something has set a non-null but empty album field on all the tracks which the MPD frontend does not like.

Received WebSocket message from 127.0.0.1: u'{"method":"core.tracklist.add","params":
[[{"__model__":"Track","name":"BBC Radio 2","uri":"tunein:station:s24940","album":{"uri":"x","name":""}}

The returned tunein search results have just a name and a uri for each track. And so it's musicbox webclient that's adding this extra garbage album field when it adds the tracks to the tracklist.

As expected, playing tunein search results works just fine using GMPC.

But if you are certain you're only seeing this with BBC stations then we must be dealing with another issue.

[kingosticks]

I think what I observed above relating to musicbox webclient is probably a different issue to what you are seeing @jackrichardson. But I have still not been able to recreate your problem when playing any BBC stream for an extended length of time on my raspbian system. I will try with pimusicbox next week, perhaps the problem is related to that.

[jackrichardson]

This seems to occur for more stations than just the BBC. Also, I have the problem when playing from search results and when browsing.
When I refer to crashing, the WebClient stops and the radio stops playing. To get it back again I run 'sudo service mopidy restart'.

[jackrichardson]

I'm now running pimusicbox 0.5.1 RC, and BBC radio stations still crash mopidy when playing with tunein.

[kingosticks]

Could you give me a step by step way to recreate the crash? Or get a log
file? Better yet, get a stack trace of the crash?
On 16 Nov 2014 11:30, "jackrichardson" notifications@github.com wrote:

I'm now running pimusicbox 0.5.1 RC, and BBC radio stations still crash
mopidy when playing with tunein.

—
Reply to this email directly or view it on GitHub
#10 (comment)
.

[jackrichardson]

Sadly, I'm a mere layman, and don't know how to provide you with a stack trace.

Recreating the crash is as simple as searching for or clicking on BBC Radio 4 (if you have it as a saved stream) in the web client and waiting around 2 hours for it to crash.

[adamcik]

Could be mopidy/mopidy#794

[kingosticks]

When you first reported this (ages ago now, sorry) I wasn't able to
reproduce this at all on my system. I will try again with the musicbox
version you mention when I get time to set it up (and find the moving box
with my raspberry pis in!)

@adamcik, I'm not convinced that would cause a crash after 2 hours. Could
it even cause a crash at all? I'd have thought it'd just fail to play a
playlist type it didn't understand.
On 16 Nov 2014 11:49, "Thomas Adamcik" notifications@github.com wrote:

Could be mopidy/mopidy#794 mopidy/mopidy#794

—
Reply to this email directly or view it on GitHub
#10 (comment)
.

[jackrichardson]

Is it anything to do with that fact that the BBC change the tag number of their radio streams every couple of hours?:
http://volumio.org/forum/auto-updating-tagged-radio-streams-bbc-t527.html#p1943

[kingosticks]

That does sound suspicious, good spot. Whether or not it results in a
crash, rather than just stopping, could be pi specific. I wonder how the
url changeover is supposed to work.

Is it anything to do with that fact that the BBC change the tag number of
their radio streams every couple of hours?:
http://volumio.org/forum/auto-updating-tagged-radio-streams-bbc-t527.html#p1943

—
Reply to this email directly or view it on GitHub
#10 (comment)
.

[jackrichardson]

If it is of any interest, when I use the Dirble BBC Radio 4 stream on pimusicbox, rather than TuneIn, it seems to play indefinitely, with no stoppage after a couple of hours.

[kingosticks]

So my pi setup has finally been found in a moving box and I am going again. I tried with Radio 2 on Saturday and it was still playing until Sunday evening when I tried it. Unfortunately the log dies after this thanks to my helpful other half randomly turning things off. http://dpaste.com/2RE9K3M I do not understand why I cannot reproduce this, perhaps radio 2 doesnt work the same way as the other BBC stations.

[jackrichardson]

Did another test today with two pis running an identical config side-by-side. They both ran for a few hours playing Radio 4, and then both stopped at the same moment, which appears to indicate that what upsets the pis is at the BBC's end. After they stopped, I attempted to change the radio station, but attempting this made mopidy become unresponsive to any command. To make it responsive, I had to restart the mopidy service.

To ensure it wasn't Radio 4 specific, a little later I conducted the same test with Radio 2 and experienced the exact same outcome. Additionally, to ensure the problem wasn't internet connection related I also did the same test using a different internet provider and router with again the same outcome.

The only thing I haven't tried yet is having one pi running Radio 4 through TuneIn, and another playing the same station at the same time through Dirble to see whether the problem is TuneIn specific. Having said that, I do believe the issue is TuneIn specific as I had Radio 4 running continously for a week through Dirble, but cannot achieve more than perhaps 24 hours with TuneIn running a BBC station.

The standard Mopidy log doesn't show anything when the radio stops playing, but this is what it shows when I attempted to start a radio station again after it stopped (http://dpaste.com/0XPDW7Y).

Could you remind me how I can get TuneIn to report in the log file?

[kingosticks]

Can I just check that are you in the UK? Perhaps the stream playlists resolve differently when located elsewhere.

[jackrichardson]

Hertfordshire

[kingosticks]

Damn!

Since I have never understood how logging works in python this is probably a stupid way of doing it.. but I changed my /etc/mopidy/logging.conf file to the following:

[loggers]
keys = root

[handlers]
keys = fileHandler

[formatters]
keys = simpleFormatter

[logger_root]
#level = INFO
#level = WARNING
handlers = fileHandler

[loglevels]
mopidy_tunein = debug
mopidy = info

[handler_fileHandler]
class = FileHandler
level = DEBUG
#level = WARNING
formatter = simpleFormatter
args = ('/var/log/mopidy/mopidy.log',)

[formatter_simpleFormatter]
format = %(asctime)s - %(levelname)-8s %(message)s
datefmt =

And then you can do cat /var/log/mopidy/mopidy.log | egrep -v "get_time_position|get_current_track"