Home of the Squeezebox™ & Transporter® network music players.
Page 3 of 6 FirstFirst 12345 ... LastLast
Results 21 to 30 of 52
  1. #21
    Senior Member
    Join Date
    Oct 2005
    Location
    Ireland
    Posts
    17,906
    You are playing a https URL . IS there any difference with a http URL ?

    I'm not sure how much of the 7.9.2 https stuff has been back ported into 7.7.7

  2. #22
    Senior Member
    Join Date
    May 2010
    Location
    London, UK
    Posts
    402
    Quote Originally Posted by bigcookie View Post
    Not sure if this helps - I thought it might be useful to share.
    Well, on a whim I subscribed to the podcast and played out the episode that you referenced (the latest one). Although I did not understand the content of Herr Steingart's briefing, he continued to brief me through my Squeezebox Classic without a hitch, for the full duration of the episode.

    For avoidance of doubt, this is the URL of the podcast feed that I subscribed to:

    Code:
    https://dasmorningbriefing.podigee.io/feed/mp3
    And this was the URL of the episode:

    Code:
    https://cdn.podigee.com/media/podcast_5030_steingarts_morning_briefing_der_podcast_episode_314_das_doppelte_dilemma_der_gruenen.mp3?v=1571288804&source=feed
    My LMS runs on an Arm5 box, Debian Buster, LMS version 7.9.2 from a quite recent nightly (August 2019), IO::Socket::SSL version 2.060.

    I can think of no obvious reason that explains why we experience a different result. Perhaps https related, or perhaps simply something else.

  3. #23
    Senior Member
    Join Date
    Oct 2005
    Location
    Ireland
    Posts
    17,906
    mplayer only fetches data as it is required for playing - no prefetching whole files.

    The podcast reliably breaks down after 1 minute when I use mplayer on a Ubuntu system with no cache.
    The podcast plays OK using mplayer with a 32kb cache. Haven't tested very often but cache level only occasionally goes down to 0% - so I think amount of cached data is not the issue.

    Thinking some more, when using https URL - LMS is handling all the https stuff and so is behaving as if "proxied streaming" is enabled.

    So to be thorough and exclude the possibility of a https issues - test playing the http url

    edit:

    What version of IO::Socket::SSL do you have ? Some old versions don't handle hang with some SSL/TLS stuff.

  4. #24
    Senior Member
    Join Date
    May 2010
    Location
    London, UK
    Posts
    402
    Quote Originally Posted by mrw View Post
    he continued to brief me through my Squeezebox Classic without a hitch, for the full duration of the episode.
    Well, an update.

    I have now repeated the process, on the current and an earlier episode, and am now experiencing the same issue as bigcookie, that is, playback is now stopping after four or five minutes, as originally reported.

    So, my original success might have been a (temporary) fluke. I don't have any further insight at this point.

  5. #25
    Just for completeness: I changed the URL to http instead of https - I still have the same problem: podcast stops in between. This is not really helpful as anyone will understand :-). Any other ideas?

    Addon: I moved to the aac version of the podcast by changing the URL ending from mp3 to aac. After the good thing: didnt stop after 5 minutes, but it stopped after 7 minutes... This is better, but still annoying and not usable.
    --
    LMS auf einem QNAP TS-653B in einem Debian Docker-Container
    Versionsnummer: Logitech Media Server Version: 7.9.2 - 1571226194 @ Wed Oct 16 14:20:53 CEST 2019
    Player: 1x SB Touch, 5x SB Radio, 1x SB Duet.

  6. #26
    Senior Member
    Join Date
    Oct 2005
    Location
    Ireland
    Posts
    17,906
    Quote Originally Posted by bigcookie View Post
    This is not really helpful as anyone will understand :-). Any other ideas?
    Technically we know the cause of the problem - basically the podcast server doesn't like keeping an stream open that doesn't "move" - the server has been setup and tuned to download the podcast as a file (i.e. quick download) and not stream (i.e. download takes same time as it takes to play the file - short bursts of data downloaded with very long gaps in between with no activity).

    No easy answer on the LMS side. We are only suggesting readily available things that might change the timing enough to keep the server happy.

  7. #27
    Understood. I will also move back to the mp3 feed as aac at least in my case seems to block fast forwarding (even worse as I cannot workaround the situation).

    @bpa: Is there any setting on mplayer side or similar you know of, that I can change the caching so bigger chunks might be downloaded? I will also contact the stream provider - potentially there is a way...

    Thanks for the feedback!!!!
    --
    LMS auf einem QNAP TS-653B in einem Debian Docker-Container
    Versionsnummer: Logitech Media Server Version: 7.9.2 - 1571226194 @ Wed Oct 16 14:20:53 CEST 2019
    Player: 1x SB Touch, 5x SB Radio, 1x SB Duet.

  8. #28
    Senior Member
    Join Date
    Oct 2005
    Location
    Ireland
    Posts
    17,906
    Quote Originally Posted by bigcookie View Post
    Understood. I will also move back to the mp3 feed as aac at least in my case seems to block fast forwarding (even worse as I cannot workaround the situation).
    Not sure if you are talking about an AAC stream (ADTS format) or AAC podcast (MPEG4). MPEG4 AAC podcast have particular format difficulties and LMS just does enough to stream them.

    @bpa: Is there any setting on mplayer side or similar you know of, that I can change the caching so bigger chunks might be downloaded? I will also contact the stream provider - potentially there is a way...
    Not sure why you bring mplayer into this - it is not part of LMS. I mentioned it just to confirm the underlying issue with a non LMS system. I also mentioned when I increase the cache (i.e use the mplayer -cache command line option) podcast plays OK. I think (would need to be confirmed) LMS player cache slowly gets depleted and so it stops. Mplayer with no cache stops after 1 min. Mplayer with a small cache which is not depleted plays OK.

    Usually sites which configure the servers in this way do it consciously to reduce network load/costs (i.e avoid users streaming, keeping number of network connection to a minimum which would otherwise block access to the site).

  9. #29
    Mplayer: my fault. I misread one of the posts above.

    Aac: the site provides two streaming formats: aac and mp3. I simply tried both in case it might change the behavior - it didnt

    I agree with the remark on streaming vs download costs.

    If i cone across a solution, I will share it. I could run a script daily, downloading the latest episode (same file/ overwrite), potentially initiate a db rescan and then simple playback...
    Will think about it :-).

    Thanks again!
    --
    LMS auf einem QNAP TS-653B in einem Debian Docker-Container
    Versionsnummer: Logitech Media Server Version: 7.9.2 - 1571226194 @ Wed Oct 16 14:20:53 CEST 2019
    Player: 1x SB Touch, 5x SB Radio, 1x SB Duet.

  10. #30
    Senior Member
    Join Date
    Oct 2005
    Location
    Ireland
    Posts
    17,906
    Quote Originally Posted by bigcookie View Post
    If i cone across a solution, I will share it. I could run a script daily, downloading the latest episode (same file/ overwrite), potentially initiate a db rescan and then simple playback...
    Will think about it :-).
    I don't there is an easy solution.

    Within LMS there is no way to tell the difference between an remote MP3 stream and a podcast (extension, mime & URL designations - same for both) - so any special processing would have to happen at the Podcast plugin level and would have to create a new type to label podcast URL as a podcast and not just a remote MP3 stream (e.g. change saved URL from http:// to podcast://). MPEG-4 podcast can be distinguished but handling all podcast the same may be easier as there are very few http/MPEG-4 streams (i.e. no duration) as MPEG-4 is normally streamed with HLS or DASH.

    Once identified, then the simplest way to stream and provide intermediate caching would be to tell LMS to use a "transcoder" - which does nothing to data but buffers data and also facilitates "jump to time".

    Unfortunately to get metadata from the stream and to enable seeking a time point through a "transcoder" - means some more work in terms of a new Protocol handler - much of which will probably be passed to current LMS processing but still needs intercepting etc.

Tags for this Thread

Posting Permissions

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