Home of the Squeezebox™ & Transporter® network music players.
Page 1 of 4 123 ... LastLast
Results 1 to 10 of 137

Hybrid View

  1. #1
    Senior Member
    Join Date
    Jan 2010
    Location
    Hertfordshire
    Posts
    9,422

    Radio station stops playing

    The radio station Delicious Agony
    http://www.deliciousagony.com/listen.pls
    stops playing after a time when played on a Touch or a Radio. It doesn't stop when played on my mpd player via the upnp/DLNA bridge. It seems to stop directly after a station ID message. Proxied streaming doesn't help.
    All thoughts welcome


    Sent from my Pixel 3a using Tapatalk

  2. #2
    Senior Member
    Join Date
    Oct 2005
    Location
    Ireland
    Posts
    21,827
    Quote Originally Posted by slartibartfast View Post
    The radio station Delicious Agony
    http://www.deliciousagony.com/listen.pls
    stops playing after a time when played on a Touch or a Radio. It doesn't stop when played on my mpd player via the upnp/DLNA bridge. It seems to stop directly after a station ID message. Proxied streaming doesn't help.
    First thoughts.
    Although there are some icy headers - there is no icy-metaint which would allow for metadata to be inserted into the audio stream - so I think for an ID to be added mid stream is wrong.

    I'll testing it using ffplay with logging to see what happens

  3. #3
    Senior Member
    Join Date
    Oct 2005
    Location
    Ireland
    Posts
    21,827
    It looks like there is icy metadata within the stream and LMS seems to handle it OK - maybe there is a default icy-metaint setting as I think no icy-metaint is unusual. I think checking how metadata is encoded in the stream and what LMS expects is a starting point.

    IIRC "icy" is not a documented technology except in source code and so variations occurs.

  4. #4
    Senior Member
    Join Date
    Jan 2010
    Location
    Hertfordshire
    Posts
    9,422
    Quote Originally Posted by bpa View Post
    It looks like there is icy metadata within the stream and LMS seems to handle it OK - maybe there is a default icy-metaint setting as I think no icy-metaint is unusual. I think checking how metadata is encoded in the stream and what LMS expects is a starting point.

    IIRC "icy" is not a documented technology except in source code and so variations occurs.
    Is there a logging setting in LMS I can set?
    Does the fact that the DLNA mpd player on a Pi isn't affected give a clue?

    Sent from my Pixel 3a using Tapatalk

  5. #5
    Senior Member
    Join Date
    Oct 2005
    Location
    Ireland
    Posts
    21,827
    Quote Originally Posted by slartibartfast View Post
    Is there a logging setting in LMS I can set?
    Does the fact that the DLNA mpd player on a Pi isn't affected give a clue?

    Sent from my Pixel 3a using Tapatalk
    my bad- there is an icy-metaint set at 16000 - it just oddly placed as the very last header after "Expires" -

    That said - I have had a break in playing and it was just after a icy metadata.

    You can see when metadata is being parsed by logging formats.metadata to DEBUG and player.streaming.remote to DEBIG (not sure which is key).

  6. #6
    Senior Member
    Join Date
    Oct 2005
    Location
    Ireland
    Posts
    21,827
    player.streaming.remote set to DEBUG will show the metadata parsing in remote streams

    Code:
    22-06-21 13:18:59.2236] Slim::Player::Protocols::HTTP::parseMetadata (286) Icy metadata received: StreamTitle='Helloween - Don't Run For Cover, from the 1985 album `Walls Of Jericho`';
    Since there is silence - initial ideas (i) LMS stream processing has stopped or (ii) MP3 decoding has broken.

    If player.streaming.remote logging is set to DEBUG then if stream is still "playing" - new metadata should keep appearing as long as stream is being played - this seems to be true for both direct and proxied.

    If metadata keeps appearing but stream is silent then it would seem MP3 decode is at issue.
    If metadata stops appearing - then it would appear that reading data from station has stopped.

  7. #7
    Senior Member
    Join Date
    Apr 2005
    Location
    UK/London
    Posts
    5,983
    I was thinking of a workaround after enabling indirect streaming - as something that might be easier than patching Touch/Radio and lots of Jogglers running SqueezePlay.
    Paul Webster
    Author of "Now Playing" plugins covering Radio France (FIP etc), PlanetRadio (Bauer - Kiss, Absolute, Scala, JazzFM etc), KCRW, ABC Australia and CBC/Radio-Canada
    and, via the extra "Radio Now Playing" plugin lots more - see https://forums.slimdevices.com/showt...Playing-plugin

  8. #8
    Senior Member
    Join Date
    Oct 2005
    Location
    Ireland
    Posts
    21,827
    Quote Originally Posted by Paul Webster View Post
    I was thinking of a workaround after enabling indirect streaming - as something that might be easier than patching Touch/Radio and lots of Jogglers running SqueezePlay.
    As I see it, the problem with the affected systems is they have ALSA and to change characteristic mid stream you need to reopen the ALSA device - which is not happening and maybe difficult to fix. Is it worth it for 1 stream which is not obeying convention ?

    A few years I created a simple plugin which defined a special URL such as "xplay://" not unlike WaveInput plugin . It basically replaced the "xplay:" by "http" and ran the stream through ffmpeg forced into CD quality output - it meant any stream could be played but you lost embedded metadata. There is minimal code - forcing the use rule in a custom-convert.conf

    To save metadata - a plugin is needed but would have to have protocol handler to get the metadata and then feed the audio stream through something like ffmpeg.

    The above assume ffmpeg can handle the issue. sox cannot handle http input so sox is only applicable to a plugin which has a protocol handler.

    edit:

    Looking at ALSA api - it may not necessary to reopen ALSA device just toi change a hardware param but not sure if it would work in practice.
    Last edited by bpa; 2022-06-22 at 15:25.

  9. #9
    Senior Member
    Join Date
    Jan 2010
    Location
    Hertfordshire
    Posts
    9,422
    Quote Originally Posted by bpa View Post
    As I see it, the problem with the affected systems is they have ALSA and to change characteristic mid stream you need to reopen the ALSA device - which is not happening and maybe difficult to fix. Is it worth it for 1 stream which is not obeying convention ?

    A few years I created a simple plugin which defined a special URL such as "xplay://" not unlike WaveInput plugin . It basically replaced the "xplay:" by "http" and ran the stream through ffmpeg forced into CD quality output - it meant any stream could be played but you lost embedded metadata. There is minimal code - forcing the use rule in a custom-convert.conf

    To save metadata - a plugin is needed but would have to have protocol handler to get the metadata and then feed the audio stream through something like ffmpeg.

    The above assume ffmpeg can handle the issue. sox cannot handle http input so sox is only applicable to a plugin which has a protocol handler.

    edit:

    Looking at ALSA api - it may not necessary to reopen ALSA device just toi change a hardware param but not sure if it would work in practice.
    Do we know why squeezelite players aren't affected?

    Sent from my Pixel 3a using Tapatalk

  10. #10
    Senior Member
    Join Date
    Oct 2005
    Location
    Ireland
    Posts
    21,827
    Quote Originally Posted by slartibartfast View Post
    Do we know why squeezelite players aren't affected?
    No. It would need looking at the code - IIRC don't they use a library called PortAudio.

    I think the simplest way to test any player would be to create a MP3 file which has two types of audio formats in the same file (e.g. test tone 20sec @44.1Khz and same tone then 20 sec @ 22.05kHz).

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •