Home of the Squeezebox™ & Transporter® network music players.
Page 2 of 2 FirstFirst 12
Results 11 to 19 of 19
  1. #11
    Senior Member
    Join Date
    Oct 2005
    Location
    Ireland
    Posts
    20,753
    Quote Originally Posted by bobertuk View Post
    This may or may not be relevant/useful! I'm running the latest version of Windows 10 with all current updates and the latest LMS nightly 8.2. Have only ever been able to get PlayHLS v2.7 even though there's a v2.8 available somewhere (maybe Linux only?). With PlayHLS v2.7 Spotify playlists are not found and scanning generally appears curtailed. I haven't investigated, it was just easier and quicker to uninstall PlayHLS and rescan. Over time I have made several attempts to use PlayHLS v2.7, originally with LMS 7.9 and with new Windows 10 installs so this for me is a longstanding problem. I haven't investigated any further because I'm not sure how relevant HLS is for me but it appears there is something interfering with LMS scan.
    This sounds like a "PlayHLS plugin issue" and not a "future of HLS in LMS" issue and so should best be handled in the plugin own thread. To continue please repost on the PlayHLS support thread. https://forums.slimdevices.com/showt...LS-m3u8-stream

    2.8 is part of the PlayHLS update so update should happen normally - V2 of the plugin is platform agnostic.

    No HLS playlist appearing in Spotify sound like a Spotify plugin issue in the same was Tune-in will not show HLS stream unless the "type" hls is defined - this sounds like a Spotify issue. PlayHLS does not deal finding playlist or with the source of playlist just playing them.

  2. #12
    Senior Member
    Join Date
    May 2008
    Location
    Canada
    Posts
    7,481
    Quote Originally Posted by bpa View Post
    Sorry for the dump of posts but HLS has been in my head for the last month or two and it'll be gone once I stop working on the plugin.
    Thanks for answering, this is very helpful. This is the kind of discussion I was hoping to have. I have to think about it more, but keeping HLS or DASH as a plugin, even if it's internal to LMS would prevent 3rd party plugins to really depends on them no?

    I was thinking about that after I finally found a way to have Reliable & Cache as a core HTTP package (which I could not do at the beginning) as it could provide the easiest way for 3rd party plugins to use HLS / DASH. All they would have to do is to get the manifest files and the built-in protocol handler would take care of all the rest. So that sounds to me like a set of Slim::Player::Protocols::HLS.pm and Slim::Player::Protocols:ASH.pm. I can't say that I'm absolutely sure of that, though.

    That also led me to think about versions now. I was asking @mherger if we should not

    - Release 8.1.2 and say it's done, no further fixes
    - Release 8.2 and call it stable, which means 8.2.x will only provide bug fixes (if we do that I'll have one or two last proposals )
    - Open a 8.3 (or beyond!) to work on that topic, and maybe others
    LMS 8.2 on Odroid-C4 - SqueezeAMP!, 5xRadio, 5xBoom, 2xDuet, 1xTouch, 1xSB3. Sonos PLAY:3, PLAY:5, Marantz NR1603, Foobar2000, ShairPortW, 2xChromecast Audio, Chromecast v1 and v2, Squeezelite on Pi, Yamaha WX-010, AppleTV 4, Airport Express, GGMM E5, RivaArena 1 & 3

  3. #13
    Senior Member
    Join Date
    Oct 2005
    Location
    Ireland
    Posts
    20,753
    Quote Originally Posted by philippe_44 View Post
    Thanks for answering, this is very helpful. This is the kind of discussion I was hoping to have. I have to think about it more, but keeping HLS or DASH as a plugin, even if it's internal to LMS would prevent 3rd party plugins to really depends on them no?
    I don't see why it would prevent them. I think it is similar to saying faad is bundled with LMS - I suggest the HLS plugin are bundled with a normal LMS. If I finish the PlayHLSv3 - then it can be included in a 8.1.* and 8.2.* release without any changes to core LMS.

    Currently, this plugin approach already works. Tune-in (Internetradio fixURL routine in Tunein.pm) detects "presence" of HLS support (ignorent of plugin or core implementation) by checking if there is a "type" called "hls".

    Making HLS support available to all user of 8.* is desirable. The need for https support made upgrades to 8.* essential however I think upgrade hesistancy will re-emerge as there will seem no great need to go from 8.1 to 8.2. A plugin approach will enable PlayHLS to be included in a minor rev of 8.1 and 8.2. If it causes a user a problem the plugin can be disabled so minimise support issues.

    The more users use HLS services, the more issues will be found that need to be addressed in a "proper" integration into core LMS. The recent comment about Spotify and HLS is a case in point. I was unaware that Spotify can offer HLS streams and IIRC it has not been reported before. A mixcloud plugin update could be the test of practicality of plugins and the "dependency" issue. Mixcloud live streams use HLS fMPEG4 and some other non-live streams are in DASH.

    I was thinking about that after I finally found a way to have Reliable & Cache as a core HTTP package (which I could not do at the beginning) as it could provide the easiest way for 3rd party plugins to use HLS / DASH. All they would have to do is to get the manifest files and the built-in protocol handler would take care of all the rest. So that sounds to me like a set of Slim::Player::Protocols::HLS.pm and Slim::Player::Protocols:ASH.pm. I can't say that I'm absolutely sure of that, though.
    I haven't kept up with Reliable & Cache so I can't comment at this stage.

    That also led me to think about versions now. I was asking @mherger if we should not

    - Release 8.1.2 and say it's done, no further fixes
    - Release 8.2 and call it stable, which means 8.2.x will only provide bug fixes (if we do that I'll have one or two last proposals )
    - Open a 8.3 (or beyond!) to work on that topic, and maybe others
    With this version roll-out, I see the development as follows

    1. Finish a PlayHLS v3. Don't tackle the "rogue" streams and assess how popular they are. Include as plugin in 8.2.x (not .0) and possibly do a minor rev of 8.1
    2. Do a PlayDASH and similar to point 1.
    3. As part of 8.3 effort look at integrating HLS & DASH into core LMS as per Slim::Player::Protocols::HLS.pm and Slim::Player::Protocols:ASH.pm suggestions. Solution should also address issues found by experiences gained from plugins support of HLS and DASH.

  4. #14
    Senior Member
    Join Date
    May 2008
    Location
    Canada
    Posts
    7,481
    Quote Originally Posted by bpa View Post
    I don't see why it would prevent them. I think it is similar to saying faad is bundled with LMS - I suggest the HLS plugin are bundled with a normal LMS. If I finish the PlayHLSv3 - then it can be included in a 8.1.* and 8.2.* release without any changes to core LMS.

    Currently, this plugin approach already works. Tune-in (Internetradio fixURL routine in Tunein.pm) detects "presence" of HLS support (ignorent of plugin or core implementation) by checking if there is a "type" called "hls".

    Making HLS support available to all user of 8.* is desirable. The need for https support made upgrades to 8.* essential however I think upgrade hesistancy will re-emerge as there will seem no great need to go from 8.1 to 8.2. A plugin approach will enable PlayHLS to be included in a minor rev of 8.1 and 8.2. If it causes a user a problem the plugin can be disabled so minimise support issues.
    I was not suggesting at all no support in 8.1/8.2 and only do something beyond. I agree with plugin approach for these, I was more thinking along the lines of integrated support beyond that. I agree that if a plugin offers support for hls:// then other plugins will benefit from it if they spit out a hls:// link. I was thinking of cases where a plugins would need to subclass the PH for hls:// and that might be less "convenient" if hls:// is not a core protocol handler.

    That's an issue I had with "Reliable/Buffered" where until I integrated directly inside Slim::Protocol::Player::HTTP, then no plugin could benefit from it. But I agree, the problem is likely different here and subclassing might not be needed most of the time.

    The more users use HLS services, the more issues will be found that need to be addressed in a "proper" integration into core LMS. The recent comment about Spotify and HLS is a case in point. I was unaware that Spotify can offer HLS streams and IIRC it has not been reported before. A mixcloud plugin update could be the test of practicality of plugins and the "dependency" issue. Mixcloud live streams use HLS fMPEG4 and some other non-live streams are in DASH.

    With this version roll-out, I see the development as follows

    1. Finish a PlayHLS v3. Don't tackle the "rogue" streams and assess how popular they are. Include as plugin in 8.2.x (not .0) and possibly do a minor rev of 8.1
    2. Do a PlayDASH and similar to point 1.
    3. As part of 8.3 effort look at integrating HLS & DASH into core LMS as per Slim::Player::Protocols::HLS.pm and Slim::Player::Protocols:ASH.pm suggestions. Solution should also address issues found by experiences gained from plugins support of HLS and DASH.
    Agreed in general, although I would do a bit different with a "built-in plugin" in a 8.3 then, a 3rd party plugin in 8.1/8.2 and then a core integration in 8.4
    LMS 8.2 on Odroid-C4 - SqueezeAMP!, 5xRadio, 5xBoom, 2xDuet, 1xTouch, 1xSB3. Sonos PLAY:3, PLAY:5, Marantz NR1603, Foobar2000, ShairPortW, 2xChromecast Audio, Chromecast v1 and v2, Squeezelite on Pi, Yamaha WX-010, AppleTV 4, Airport Express, GGMM E5, RivaArena 1 & 3

  5. #15
    Senior Member
    Join Date
    Oct 2005
    Location
    Ireland
    Posts
    20,753
    Quote Originally Posted by philippe_44 View Post
    I was not suggesting at all no support in 8.1/8.2 and only do something beyond. I agree with plugin approach for these, I was more thinking along the lines of integrated support beyond that. I agree that if a plugin offers support for hls:// then other plugins will benefit from it if they spit out a hls:// link. I was thinking of cases where a plugins would need to subclass the PH for hls:// and that might be less "convenient" if hls:// is not a core protocol handler.
    I haven't come across a need for a hls:// accessible to third party plugin. HLS URLs are http/https with appropriate HLS mime type. Plugins such as iHeart or Tune-in just return a http URL. The plugin takes it when users tries to play the http URL and LMS determines type from MIME. To avoid LMS recursing on http m3u8 URL (which occur many times within m3u8 playlist) - the plugin replaces all http URLs during initial processing by its own URL hlsplay:// to avoid default LMS http processing.

    That's an issue I had with "Reliable/Buffered" where until I integrated directly inside Slim::Protocol::Player::HTTP, then no plugin could benefit from it. But I agree, the problem is likely different here and subclassing might not be needed most of the time.
    This is where I have no knowledge of your use cases and the need for other plugin to access hls:// or to subclass. It seems unnecessary but as HLS plugin has to handle content as well - multiple audio formats - subclassing may be appropriate but I'd need to study Reliable/ cache to understand.

    I think having a plugin in 8.1/8.2 will show up show HLS will be used and whether subclasses or access to hls:// is required. Perhaps this Spotify issue might be the test case.

    Agreed in general, although I would do a bit different with a "built-in plugin" in a 8.3 then, a 3rd party plugin in 8.1/8.2 and then a core integration in 8.4
    OK - this is more gradual but I'm OK with it.

  6. #16
    Babelfish's Best Boy mherger's Avatar
    Join Date
    Apr 2005
    Location
    Switzerland
    Posts
    20,587

    HLS, DASH, MPD and LMS future version

    Hi bpa

    thank you very much for your brain dump! That's super helpful for me to
    get a better understanding of where things stand today. I did know the
    very basics of HLS (briefly looked into it years back, when Sirius did
    the switch). But that was about it.

    > I'm not sure of the shortcomings of an LMS standard PlayHLS plugin vs
    > LMS core code.


    I was wondering too. For me the plugins still represent functionality
    which can be optional, which a user would want to turn off for whatever
    reason. Sure, code separation is a good thing, too. But for something
    like HLS etc. I feel it's more of an enhancement nobody should have to
    enable manually. Or would want to disable.

    But really: whatever path you'd take, I'd be greatful. You and Philippe,
    you're the experts here :-).

  7. #17
    Babelfish's Best Boy mherger's Avatar
    Join Date
    Apr 2005
    Location
    Switzerland
    Posts
    20,587

    HLS, DASH, MPD and LMS future version

    > I don't see why it would prevent them. I think it is similar to saying
    > faad is bundled with LMS - I suggest the HLS plugin are bundled with a
    > normal LMS. If I finish the PlayHLSv3 - then it can be included in a
    > 8.1.* and 8.2.* release without any changes to core LMS.


    I'd hesitate to include it in 8.1. That should be bug fixes only. But we
    should probably stabilize/release 8.2 and include it there? Make that
    "the release", then start a new branch with more experimental work, core
    integration or whatever.

    > Currently, this plugin approach already works. Tune-in (Internetradio


    Laggers who'd want to stick with 8.1 can still use the plugin, but would
    have to install it themselves, right?

    > Making HLS support available to all user of 8.* is desirable. The need
    > for https support made upgrades to 8.* essential however I think upgrade
    > hesistancy will re-emerge as there will seem no great need to go from
    > 8.1 to 8.2. A plugin approach will enable PlayHLS to be included in a
    > minor rev of 8.1 and 8.2. If it causes a user a problem the plugin can
    > be disabled so minimise support issues.


    But isnt't that the case with the plugin as a 3rd party addition
    already? Users can enable it if they want to?

    > The more users use HLS services, the more issues will be found that need
    > to be addressed in a "proper" integration into core LMS. The recent
    > comment about Spotify and HLS is a case in point. I was unaware that
    > Spotify can offer HLS streams and IIRC it has not been reported before.


    That's news to me, too. From discussions within the librespot community
    I must assume that might have been a podcast. Podcast integration seems
    to be much more driven by the podcast provider than with regular music.
    Eg. streams would/could come from those services, not Spotify.

    >> That also led me to think about versions now. I was asking @mherger if
    >> we should not
    >>
    >> - Release 8.1.2 and say it's done, no further fixes
    >> - Release 8.2 and call it stable, which means 8.2.x will only provide
    >> bug fixes (if we do that I'll have one or two last proposals )
    >> - Open a 8.3 (or beyond!) to work on that topic, and maybe others


    I'd second that plan. Although I'd suggest we could include HLS as a
    plugin in 8.2. It then could easily be disabled if somebody wanted to
    for whatever reason (as bpa outlined).

    > 1. Finish a PlayHLS v3. Don't tackle the "rogue" streams and assess how
    > popular they are. Include as plugin in 8.2.x (not .0) and possibly do a
    > minor rev of 8.1


    Why not in v8.2.0?

    I'd vote against 8.1. Once 8.2.0 released, any work on 8.1. should stop.
    I don't want to maintain three branches...

    > 3. As part of 8.3 effort look at integrating HLS & DASH into core LMS as
    > per Slim::Player::Protocols::HLS.pm and
    > Slim::Player::Protocols:ASH.pm suggestions. Solution should also
    > address issues found by experiences gained from plugins support of HLS
    > and DASH.


    Sounds like a plan!

  8. #18
    Senior Member
    Join Date
    Oct 2005
    Location
    Ireland
    Posts
    20,753
    Quote Originally Posted by mherger View Post

    > 1. Finish a PlayHLS v3. Don't tackle the "rogue" streams and assess how
    > popular they are. Include as plugin in 8.2.x (not .0) and possibly do a
    > minor rev of 8.1


    Why not in v8.2.0?

    I'd vote against 8.1. Once 8.2.0 released, any work on 8.1. should stop.
    I don't want to maintain three branches...
    [color=blue]
    Had to pick a starting point to see what reaction would be. Not sure how aggressive a plan was wanted.

    I'm OK with 8.2.

    It would then fit in with a small LMS change - unzip/inflate HTTP gzipped responses that will be processed by SLim::Utils::Scanner::Remote::readRemoteHeaders as some m3u8 playlists are gzipped. I'll do a PR but I'm still slow with git.

    Sounds like a plan!
    OK.

  9. #19
    Senior Member
    Join Date
    Oct 2005
    Location
    Ireland
    Posts
    20,753
    Quote Originally Posted by mherger View Post

    > The more users use HLS services, the more issues will be found that need
    > to be addressed in a "proper" integration into core LMS. The recent
    > comment about Spotify and HLS is a case in point. I was unaware that
    > Spotify can offer HLS streams and IIRC it has not been reported before.


    That's news to me, too. From discussions within the librespot community
    I must assume that might have been a podcast. Podcast integration seems
    to be much more driven by the podcast provider than with regular music.
    Eg. streams would/could come from those services, not Spotify.
    Spotify - I think just need to be aware. It looks to be a scanning issue rather than streaming one but I struggle to understand why the two plugins could clash on scanning as I believe HLS is not used on Spotify.

    Quote Originally Posted by bobertuk View Post
    With PlayHLS v2.7 Spotify playlists are not found and scanning generally appears curtailed. I haven't investigated, it was just easier and quicker to uninstall PlayHLS and rescan.
    I know there are other users of Spotify and PlayHLS V2.* and I've had no reports of a scanning issue but perhaps they are not using Spotify playlists or not on Win10.

    User is also using PlayHLS 2.7 and say can't find/install 2.8 and also on Win10 - so I wonder if there are other issues/system specifics.

Posting Permissions

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