Home of the Squeezebox™ & Transporter® network music players.
Page 199 of 201 FirstFirst ... 99149189197198199200201 LastLast
Results 1,981 to 1,990 of 2009
  1. #1981
    Junior Member
    Join Date
    Jun 2021
    Posts
    3
    Is host mode actually essential? I usually just identify the ports needed and keep things contained that way. So far I have -p 49152-49252:49152-49252 but that alone isn't doing the trick. What other ports does this need?

  2. #1982
    Senior Member
    Join Date
    May 2008
    Location
    Canada
    Posts
    7,564
    Quote Originally Posted by Dakos View Post
    Is host mode actually essential? I usually just identify the ports needed and keep things contained that way. So far I have -p 49152-49252:49152-49252 but that alone isn't doing the trick. What other ports does this need?
    You need host mode. No NAT can be used as the bridge creates a HTTP server on the host.
    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. #1983
    Senior Member
    Join Date
    Oct 2014
    Location
    Pittsburgh PA
    Posts
    220

    CastBridge players no longer respond to 'mute' commands

    Beginning with the current release (v1.64.0), client 'mute' commands are being ignored by all my CastBridge players. I thought maybe it was due to a recent LMS upgrade from v8.1.2 to v8.2, but non-Chromecast players are unaffected.

    Edit: I just realized that the failed mute requests are accompanied by the following log error message:

    Code:
    [21-07-17 18:53:20.5139] Slim::Control::Request::execute (1888) Error: While trying to run function coderef [Slim::Control::Commands::mixerCommand]: [Can't call method "mute" on unblessed reference at /usr/share/perl5/Slim/Control/Commands.pm line 3274.]
    Last edited by SamY; 2021-07-17 at 17:03. Reason: Add error message from LMS log
    Sam

  4. #1984
    Senior Member
    Join Date
    May 2008
    Location
    Canada
    Posts
    7,564
    Quote Originally Posted by SamY View Post
    Beginning with the current release (v1.64.0), client 'mute' commands are being ignored by all my CastBridge players. I thought maybe it was due to a recent LMS upgrade from v8.1.2 to v8.2, but non-Chromecast players are unaffected.

    Edit: I just realized that the failed mute requests are accompanied by the following log error message:

    Code:
    [21-07-17 18:53:20.5139] Slim::Control::Request::execute (1888) Error: While trying to run function coderef [Slim::Control::Commands::mixerCommand]: [Can't call method "mute" on unblessed reference at /usr/share/perl5/Slim/Control/Commands.pm line 3274.]
    Should be fixed in 1.64.1
    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. #1985
    Senior Member
    Join Date
    Oct 2014
    Location
    Pittsburgh PA
    Posts
    220
    Quote Originally Posted by philippe_44 View Post
    Should be fixed in 1.64.1
    Sounds good. Thanks, Philippe.
    Sam

  6. #1986
    Member
    Join Date
    Jun 2020
    Location
    UK
    Posts
    65

    Long songs over 10 minutes

    Hopefully this is in the right place as I haven't been able to completely be sure where the issue lies.

    I'm having a problem in the last couple of days playing tracks over 10 minutes from Spotify via Chromecast Audio and Airplay

    The Following instances

    1) track Shine on you crazy Diamond parts 1-7 duration 17:32 from spotify over airplay bridge. Track ends prematurely around 12 minutes and crossfades with the next rack in the queue. I have this track locally but at a lower bit rate and it played right through.

    2) track Schuberts Octet 1st movement https://open.spotify.com/track/7abavMfKPzktTyEHDnoJkd. duration 14:52 Track ended around 11 minutes. I don't have this track locally but another version of the same piece of music at a low bit rate and this played fine.

    I checked the airplay log, the chromecast log and the LMS log. I get this warning repeatedly during the airplay session.

    [21-07-23 16:50:46.1592] Slim::Utils::Misc::msg (1341) Warning: [16:50:45.8050] Use of uninitialized value in concatenation (.) or string at C:\ProgramData\Squeezebox\Cache\InstalledPlugins\P lugins\RaopBridge\HTML\EN\plugins\RaopBridge\setti ngs\basic.html line xxx.

    In the Chromecast log though I Get the following issue

    [09:36:23.830] CastSetDeviceVolume:325 [0048D9C8]: Immediate VOLUME (id:811)
    [09:39:46.572] _SyncNotifyState:424 [0048D9C8]: Cast stop
    [09:39:46.572] slimproto_run:749 [004B2204]: Track shorter than expected (643922/892320)
    [09:39:46.588] sendSTAT:169 [004B2204]: STAT:[STMd] msplayed 643922
    [09:39:46.588] sendSTAT:169 [004B2204]: STAT:[STMu] msplayed 643922
    [09:39:46.697] process_strm:238 [004B2204] strm command s
    [09:39:46.697] process_strm:307 [004B2204], strm s autostart: 1 transition period: 5 transition type: 0 codec: o
    [09:39:46.697] sendSTAT:169 [004B2204]: STAT:[STMf] msplayed 643922
    [09:39:46.760] sq_callback:299 [0048D9C8]:
    artist:Franz Schubert, Gidon Kremer, Isabelle van Keulen, Tabea Zimmermann, David Geringas, Alois Posch, Eduard Brunner, Radovan Vlatkovic, Klaus Thunemann
    album:Schubert: Octet D 803

    The final test was then to enable debug logging on the spotty plugging as I thought that might be the issue and played the Schubert Octet again and it played without issue.

    So I'm thinking that the problem is in the chromecast bridge with the track being shorter than expected. Is this potentially an intermittent buffering issue? I seem to recall another report of problems with long songs but I can't seem to find it now.

    Any help gratefully received. Its a big pain with classical music where track durations over 10 minutes are quite common

    Thanks

  7. #1987
    Senior Member
    Join Date
    Jan 2011
    Location
    Minneapolis
    Posts
    770

    ChromeCast Syncing with other players Fails occasionaly (Hi-Res Qobuz) ......

    I posted quite a bit about this problem last year, and so I thought I'd take another try at it. The Chromecast Bridge is a very useful pluggin for myself and Audiophile Buddies.... What we are trying to do is just display the Album Art on our TVs while the Chrome-cast is synced to another Raspberry Pi Player.

    The main problem we are having is when using Qobuz and when playing a Hi-Res Track, it will cause a number of problems, sometimes causing the track to stop playing entirely. This is with the Chromecast synced to the Raspberry Pi. The Rpi is the master and the Chromecast is the Slave. But even in this configuration the Chromecast will cause the track to quit playing and basically 'freeze' the entire process. Only to start up again and freeze a minute later. Removing the Chromcast Slave and replaying the Track will correct the problem.... This track was reproducible for me. it messes up on almost every Hi-Res Track... I have the Chromecast Player Sample rate set to 192000 ..... So, maybe I am missing another Set Up ?????

    Name:  Chromecast.jpg
Views: 85
Size:  187.8 KB
    Last edited by Cut-Throat; 2021-10-08 at 13:41.

  8. #1988
    Senior Member
    Join Date
    May 2008
    Location
    Canada
    Posts
    7,564
    Quote Originally Posted by Cut-Throat View Post
    I posted quite a bit about this problem last year, and so I thought I'd take another try at it. The Chromecast Bridge is a very useful pluggin for myself and Audiophile Buddies.... What we are trying to do is just display the Album Art on our TVs while the Chrome-cast is synced to another Raspberry Pi Player.

    The main problem we are having is when using Qobuz and when playing a Hi-Res Track, it will cause a number of problems, sometimes causing the track to stop playing entirely. This is with the Chromecast synced to the Raspberry Pi. The Rpi is the master and the Chromecast is the Slave. But even in this configuration the Chromecast will cause the track to quit playing and basically 'freeze' the entire process. Only to start up again and freeze a minute later. Removing the Chromcast Slave and replaying the Track will correct the problem.... This track was reproducible for me. it messes up on almost every Hi-Res Track... I have the Chromecast Player Sample rate set to 192000 ..... So, maybe I am missing another Set Up ?????
    My recommendation is to use the "transcode" mode to mp3 at the lowest bitrate as it might be the CC itself which has a problem with the hi-res file. By transcoding it, the CC will simply saw the same format all the time and because you don't care about the audio, it will minimize your network bandwidth. Don't forget to "not maintain sync"
    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

  9. #1989
    Senior Member
    Join Date
    Jan 2011
    Location
    Minneapolis
    Posts
    770
    Quote Originally Posted by philippe_44 View Post
    My recommendation is to use the "transcode" mode to mp3 at the lowest bitrate as it might be the CC itself which has a problem with the hi-res file. By transcoding it, the CC will simply saw the same format all the time and because you don't care about the audio, it will minimize your network bandwidth. Don't forget to "not maintain sync"
    OK, Thanks Much! -- I had forgot about a few of these parameters. And setting them the way you recommended has corrected the tracks I was having problems with..... I am going to play with this again over the next few days... Thanks Again!!

  10. #1990
    Senior Member
    Join Date
    Oct 2014
    Location
    Pittsburgh PA
    Posts
    220
    Quote Originally Posted by Cut-Throat View Post
    OK, Thanks Much! -- I had forgot about a few of these parameters. And setting them the way you recommended has corrected the tracks I was having problems with..... I am going to play with this again over the next few days... Thanks Again!!
    Thanks for this idea! I have configured the players in my A/V room and bedroom to sync with their local Castbridge players and it works like a charm without any transcoding in the plugin, albeit at the expense of doubling the network traffic. However, because I am running LMS, the plugin, and all the players on an old RPi B+, choosing the option to transcode to mp3 in the plugin results in excessive cpu usage and resultant hiccups and delays in the player audio. As always, there is a tradeoff in resource consumption and, in my case, I have more available bandwidth than I do cpu. Since we are not actually using the CC audio in this scenario, I wonder if it would be possible to provide an option to not send an audio stream from the plugin at all --- only the metadata. Maybe a transcode format of 'Null'? I have no idea if it is possible but it would solve the problem of having to choose between wasting bandwidth or cpu when using the plugin in this way.
    Sam

Posting Permissions

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