🐛 | Streams and Podcasts take very long to play / don't play at all

[drybx]

Bug

I downloaded the sample content which includes podcasts and streams. All the local files play smoothly. However, streams take very long to start playing and podcasts do nothing at all.
Podcast even seem to block/crash phoniebox and I have to reboot (which takes much longer than usually).

I run Phoniebox 2.0 RC8 on the develope branch but had the same problem with versions. At some point I thought it was a DNS problem #663 but that didn't fix it.
Right now I configured 1.1.1.1 and 1.0.0.1 as DNS.
static domain_name_servers=1.1.1.1 1.0.0.1
in /etc/dhcpcd.conf

Example for podcast
http://www.kakadu.de/podcast-kinderhoerspiel.3420.de.podcast.xml

Example for stream
http://br-br2-nord.cast.addradio.de/br/br2/nord/mp3/56/stream.mp3

Any idea where I could start looking for a solution?

[s-martin]

Does this relate to #807?

[drybx]

Does this relate to #807?

I don't think so because local mp3s play without problems.

[s-martin]

Understood

[MiczFlor]

@JuliH29

• do you have the same problems with other devices, like your phone, over wifi?
• could it be that the Phoniebox IP is conflicting with another IP address in your wifi network, like a printer or the like?
• does it differ during the daytime? Sometimes, no kidding, the wifi cloud craziness in urban areas has an effect on connectivity and is better when all neighbours are asleep :)

[drybx]

Thanks for your help @MiczFlor !

* do you have the same problems with other devices, like your phone, over wifi?

No, my wifi runs smoothly. My phoniebox has the same issue in different wifis however.

* could it be that the Phoniebox IP is conflicting with another IP address in your wifi network, like a printer or the like?

Rather unlikely, as the problem appears in different wifis

* does it differ during the daytime? Sometimes, no kidding, the wifi cloud craziness in urban areas has an effect on connectivity and is better when all neighbours are asleep :)

Happens all the time, unfortunately.

I wonder if it is a connectivity issue which is rather rrelated to buster than to phoniebox. On the other hand, Spotify does not seem to be affected.
Or maybe the section of phoniebox that "resolves" xml-files of podcasts?

[drybx]

I found something via tail -n 500 /var/log/syslog

Mar 1 13:35:21 raspberrypi mopidy[456]: WARNING [StreamBackend-5] mopidy.internal.http Download of 'http://br-br2-nord.cast.addradio.de/br/br2/nord/mp3/56/stream.mp3' failed due to download taking more than 4.995s Mar 1 13:35:21 raspberrypi mopidy[456]: INFO [StreamBackend-5] mopidy.stream.actor Unwrapping stream from URI (http://br-br2-nord.cast.addradio.de/br/br2/nord/mp3/56/stream.mp3) failed: error downloading URI http://br-br2-nord.cast.addradio.de/br/br2/nord/mp3/56/stream.mp3 Mar 1 13:35:21 raspberrypi mopidy[456]: WARNING [StreamBackend-5] mopidy.stream.actor Problem looking up http://br-br2-nord.cast.addradio.de/br/br2/nord/mp3/56/stream.mp3 Mar 1 13:35:30 raspberrypi mopidy[456]: INFO [MpdSession-114] mopidy_mpd.session New MPD connection from [::ffff:127.0.0.1]:35088 Mar 1 13:35:33 raspberrypi mopidy[456]: WARNING [StreamBackend-5] mopidy.internal.http Download of 'http://br-br2-nord.cast.addradio.de/br/br2/nord/mp3/56/stream.mp3' failed due to download taking more than 4.995s Mar 1 13:35:33 raspberrypi mopidy[456]: INFO [StreamBackend-5] mopidy.stream.actor Unwrapping stream from URI (http://br-br2-nord.cast.addradio.de/br/br2/nord/mp3/56/stream.mp3) failed: error downloading URI http://br-br2-nord.cast.addradio.de/br/br2/nord/mp3/56/stream.mp3 Mar 1 13:35:33 raspberrypi mopidy[456]: WARNING [Core-10] mopidy.core.tracklist Track is not playable: http://br-br2-nord.cast.addradio.de/br/br2/nord/mp3/56/stream.mp3

I pasted the whole output here
Maybe that helps?

[s-martin]

I assume you checked, if another client can play that stream? Did wait for around 15 minutes after the box has booted, if it’s a network resolution issue?

And (probably unrelated): Your RFID Reader is not recognized:

Mar  1 13:30:06 raspberrypi python3[432]: Please run RegisterDevice.py first
Mar  1 13:30:06 raspberrypi systemd[1]: phoniebox-rfid-reader.service: Main process exited, code=exited, status=1/FAILURE

To fix this, see https://github.com/MiczFlor/RPi-Jukebox-RFID/wiki/CONFIGURE-stretch#identify-and-configure-your-rfid-reader and https://github.com/MiczFlor/RPi-Jukebox-RFID/wiki/CONFIGURE-stretch#register-your-usb-device-for-the-phoniebox

[drybx]

And (probably unrelated): Your RFID Reader is not recognized:
Thank you, I had not even realized that. Was an easy fix.

I have the same problem on different wifis and also after my phoniebox is running for more than 20 minutes.

The stream plays without problems in the browser of my computer (so the stream itself is OK).
I didn't get it to work with omxplayer on the phoniebox, but with VLC (with some funny messages though):

pi@raspberrypi:~ $ omxplayer http://br-br2-nord.cast.addradio.de/br/br2/nord/mp3/56/stream.mp3
have a nice day ;)
pi@raspberrypi:~ $ vlc http://br-br2-nord.cast.addradio.de/br/br2/nord/mp3/56/stream.mp3
VLC media player 3.0.8 Vetinari (revision 3.0.8-0-gf350b6b5a7)
[019fc518] vlcpulse audio output error: PulseAudio server connection failure: Connection refused
[01a0e1f8] main interface error: no suitable interface module
[019a0b58] main libvlc error: interface "globalhotkeys,none" initialization failed
[019a0b58] main libvlc: Running vlc with the default interface. Use 'cvlc' to use vlc without interface.
[01a0e1f8] skins2 interface error: cannot initialize OSFactory
[01a0e1f8] [cli] lua interface: Listening on host "*console".
VLC media player 3.0.8 Vetinari
Command Line Interface initialized. Type help for help.
[71400db8] http stream error: cannot resolve br-edge-20a2.fra-lg.cdn.addradio.net: Temporary failure in name resolution
[71400db8] access stream error: HTTP connection failure
[71402700] prefetch stream error: unimplemented query (264) in control

Is there anything else I can try?

[drybx]

Uh, I might have just found the solution:
I changed back the DNS in sudo nano /etc/dhcpcd.conf from 1.1.1.1 1.0.0.1 back into the IP of the router (in my case 192.168.188.1).
Now streams take a few seconds to start playing.
Podcasts take some more time but they do play.

While I'm happy about having found a solution I'm quite surprised that the Cloudflare DNS didn't work.

Update I did some more testing: Other DNS services (for example Google) work as well. Only cloudflare seems to create problems.
The only thing which does not work is podcasts via spotify.

Mar 2 22:53:02 raspberrypi mopidy[458]: INFO [SpotifyBackend-6] mopidy_spotify.lookup Failed to lookup 'spotify:episode:5GYpFrChmlyYBhF7Z1MLSj': Could not parse 'spotify:episode:5GYpFrChmlyYBhF7Z1MLSj' as a Spotify URI

[drybx]

The only thing which does not work is podcasts via spotify.

I did some research on that. Apparantly it's a general problem of the Spotify architecture. Link
So far we can just hope it will be fixed in the future, I guess.

[s-martin]

So this issue could be closed for now?

[drybx]

So this issue could be closed for now?

I guess so, as the issue is not on Phoniebox‘ side.

[drybx]

I would like to reopen this thread because I did some research on podcasts:
It seems like the time for a podcast to start playing heavily depends on the size of the xml-file:

Die Sendung mit der Maus starts playing after 15 seconds, xml-file 13 kB

Ohrenbär starts playing after 2 minutes 15 seconds, xml-file 781 kB

Lage der Nation starts playing after a very long time (more than 10 minutes), xml-file 3,2 MB

Here you can find the output of tail -n 500 /var/log/syslog after trying to play some of these podcasts. There are quite some warnings in there, but I don't have the expertise to be able to tell if they are related to my issue here.
Especially that one could be relevant:
mopidy.stream.actor Unwrapping stream from URI (https://dts.podtrac.com/redirect.mp3/cdn.kuechenstud.io/lagedernation/LdN175.mp3?ptm_source=feed&ptm_context=mp3&ptm_file=LdN175.mp3) failed: error downloading URI https://dts.podtrac.com/redirect.mp3/cdn.kuechenstud.io/lagedernation/LdN175.mp3?ptm_source=feed&ptm_context=mp3&ptm_file=LdN175.mp3 Mar 27 13:23:26 raspberrypi mopidy[5926]: WARNING [StreamBackend-5] mopidy.stream.actor Problem looking up https://dts.podtrac.com/redirect.mp3/cdn.kuechenstud.io/lagedernation/LdN175.mp3?ptm_source=feed&ptm_context=mp3&ptm_file=LdN175.mp3

Beside of that, is there any way to find out what is happening in the background?
Does everybody else experience this issue or is there something wrong with my setup?

[MiczFlor]

Hi @JuliH29

Are you using Spotify as well or the Classic edition of Phoniebox? Sorry, just saw: you are using Sptify / mopidy

Lage der Nation has a weird redirect URL in their enclosure tag:

https://dts.podtrac.com/redirect.mp3/cdn.kuechenstud.io/lagedernation/LdN178.mp3?ptm_source=feed&ptm_context=mp3&ptm_file=LdN178.mp3

... not sure if that also confuses mopidy. Is there any giganticly long RSS that plays faster?

Three thoughts:

1. Could you take a look at the RSS file and see if there are any Umlaute äüö in the filenames?
   The process in the background when playing RSS Podcasts is as such:
   a) Phoniebox downloads the xml file
   b) Phoniebox parses the xml file and takes the values (URLs) from the enclosure tags
   (here I have encountered problems if the RSS providers use Umlaute in their filenames)
   c) Phoniebox creates a list and displays this in the web UI
   d) Only when starting to play the file, Phoniebox connects the server to actually retrieve the MP3 file

2. Could this have to do not with the length of the RSS files, but the size of the MP3 files?
   Just a thought: if, like on some poorer phone apps for podcasts, the files are not streamed, but downloaded first, this could create a delay. Why the Pi should do that, I don't know, Phoniebox doesn't behave that way, it acts dumb and wants to play the remote file asap.
   If this was the case, either mpd or mopidy might have some "buffer" settings?

3. could this have anything to do with the time and date issue that sometimes also delayed the playout of spotify? See details here:
   After Powerup sound sometimes not initialized #406 (comment)
   Not sure if and how this could be related...

[Prutsium]

Tried Maus and Ohrenbear on Classic 2.0RC8 and no issues with them.
(Thanks for the tip on those streams my girly likes them)

[drybx]

Hi @MiczFlor ,

Thanks for your help.

1. Could you take a look at the RSS file and see if there are any Umlaute äüö in the filenames?

I couldn't find any Umlaute in the filenames.

2. Could this have to do not with the length of the RSS files, but the size of the MP3 files?

It's rather the opposite (Die Maus ca. 30MB, Ohrenbär ca. 10MB).

3. could this have anything to do with the time and date issue that sometimes also delayed the playout of spotify?

I don't think so because Spotify connects quite quickly and I can easily play anything from spotify.

Is there any giganticly long RSS that plays faster?
To be honest, I couldn't find any RSS file that enormous. But actually it's not so much about this podcast, which I don't want to play on my Phoniebox anyway. But Ohrenbär would be great. " minutes of loading time are just too long for a little child though.

Obviously this is a Spotify-version-only issue... Any more ideas?

[drybx]

I found this:
Mar 28 14:52:25 raspberrypi mopidy[468]: WARNING [StreamBackend-5] mopidy.internal.http Download of 'https://wdrmedien-a.akamaihd.net/medp/podcast/weltweit/fsk0/213/2131084/diemaus30_2020-03-24_kendoundkatzeninjapan_diemaus.mp3' failed due to download taking more than 4.995s
It seems there is a time limit of 5s for downloading podcasts?

[drybx]

A quick update on this:
Unfortunately podcasts are still problematic because they take a long time too load.

I get a lot of error messages like these:
May 10 12:16:55 raspberrypi mopidy[616]: WARNING [StreamBackend-5] mopidy.internal.http Download of 'https://wdrmedien-a.akamaihd.net/medp/podcast/weltweit/fsk0/215/2158520/diesendungmitdermauszumhoeren_2020-05-09_schonmalwasverkauft_diemaus.mp3' failed due to download taking more than 4.995s May 10 12:16:55 raspberrypi mopidy[616]: INFO [StreamBackend-5] mopidy.stream.actor Unwrapping stream from URI (https://wdrmedien-a.akamaihd.net/medp/podcast/weltweit/fsk0/215/2158520/diesendungmitdermauszumhoeren_2020-05-09_schonmalwasverkauft_diemaus.mp3) failed: error downloading URI https://wdrmedien-a.akamaihd.net/medp/podcast/weltweit/fsk0/215/2158520/diesendungmitdermauszumhoeren_2020-05-09_schonmalwasverkauft_diemaus.mp3

Have a look at all of them if you want.

Does anyone have an idea how we could fix this?

[bkis]

I have the same problem. syslog says mopidy is trying to download the mp3 files from the podcast (so downloading the feed seems to work!) but it fails on every mp3, trying them one by one.

I tried adding

[stream]
timeout=30000

to mopidy.conf to override the 5000 ms timeout for the mp3-stream, but it didn't work. I only tried the above mentioned podcast feed https://feeds.lagedernation.org/feeds/ldn-mp3.xml - so maybe the redirect URLs mentioned by @MiczFlor here have something to do with it, maybe they don't.

I'd love to listen to podcasts - is there anything else we could try, here? Thanks for all this!

[drybx]

I tried adding

[stream]
timeout=30000

to mopidy.conf to override the 5000 ms timeout for the mp3-stream, but it didn't work.

Interesting idea. Is there some place else where we could try to override the limit of 5000ms?
I would be so nice if we got this to work.

1. The process in the background when playing RSS Podcasts is as such:
   a) Phoniebox downloads the xml file
   b) Phoniebox parses the xml file and takes the values (URLs) from the enclosure tags
   (here I have encountered problems if the RSS providers use Umlaute in their filenames)
   c) Phoniebox creates a list and displays this in the web UI
   d) Only when starting to play the file, Phoniebox connects the server to actually retrieve the MP3 file

I'm not quite sure but to me it seems that the bug/error is actually happening during step d). Do you agree, @bkis ?

[bkis]

The logs indicate that it happens during step d), yes. Because just like in your comment it tries to address the actual mp3-URLs.
I didn't know about these steps, though. It confuses me that it should display a list in the web UI (step c)), as I haven't seen it do this, either. But maybe I just missed that or it's an unrelated problem. So yes, playing the actual file is the problem. The core-config of mopidy (stream-plugin) has 5000 ms set as a timeout - that pretty much fits the errors in the logs that say

... taking more than 4.995s ...

but it's weird that overriding the value doesn't change anything. To be fair, I didn't sink much time in this, yet. I will investigate further as soon as I have a chance.

[pofi5000]

Hi, have you found a solution yet? I'm experiencing probably the same problem with the current Spotify version.
Podcasts in the non-Spotify version worked fine.

Raspbian GNU/Linux 10 (buster)
Version 2.2 - 305325d - master
Edition Plus edition (feat. Spotify integration)

[adflord]

Hi there,
Has anyone had a new ideas about this? I can only get a couple of podcasts to work (Radio Mikro, Die Maus) and all others seem to crash the box. Even other ones from BR like DoReMikro and Betthupferl don't want to work. Also the two that do work have very long load times.

It would be really cool if we could get this feature to work!

[clutwo]

Just starting to setup a new phoniebox spotify edition. Same problem here sadly!