Home of the Squeezebox™ & Transporter® network music players.
Results 1 to 4 of 4
  1. #1

    CLI command status returns waitingToPlay=>1 answer

    Hello all,


    Some time ago i wrote a plugin for "audio bookmarks" (named "BookmarkHistory").
    This plugin subscribes to the playlist loadtracks","playlist loadalbum" and "playlist addtracks events.

    In the callback function it then retrieves the playlist of the player which triggered the event. The code is:

    Code:
    	my $numberoftracks = preferences('server')->get('maxPlaylistLength');
    	$request = Slim::Control::Request::executeRequest($client, ['status', 0 , $numberoftracks , 'tags:egu']);
    The plugin then sends a command to jump to the bookmarked track in the playlist. After that, another callback is triggered which jumps to the stored position in the track.
    I use it all the time and even if the code is terrible (perl is definitely not my preferred language...) it works reliably for me.

    One user now reported that the plugin does not work for him. It creates the bookmarks, but if he plays a boookmarked album the playback does not jump to the correct track.

    I did a bit debugging with him and discovered that the status request returns

    Code:
     waitingToPlay            => 1
    It seems that in this case the status command does not return the playlist for the client.

    In the CLI doc is just described as:
    A flag telling whether the player isn't actually playing, but still waiting for data or something.
    Whatever "something" means :-> ....


    The user has the server installed on an pretty old Synology DS1512+ NAS and he says that he has fast network connections between server and clients (Squeezebox Radio and a squeezeplay installation). I am not familiar with Synology products, but from the spec sheet this looks beefy enough to run a squeezeserver (At least it has 1GB RAM).

    I am unable to reproduce the issue. I tried throttling cpu and network speed to a ridiculous low value and built a playlist with far more than 1000 tracks. It takes about 20s until the playback starts, but the plugin works without a problem.
    I added some more debugging statements and it looks to me as if on my server the status query needs a few seconds to execute - but it never just returns with a waitingToPlay=1 value.

    So i am a bit lost here. Does anybody have a hint for me?

    Is this a really weird thing specific to his installation? Or could this happen also for other users? But as i said above: I never noticed that on one of my installations - even not on a crappy old banana pi i use for testing and as a backup installation.

    Is it possible to provoke this waitingToPlay=>1 response? Or a recommended way to handle this in a callback function? I searched through the forum but was not able to find something useful.

    Thanks a lot for any hint.

  2. #2
    Babelfish's Best Boy mherger's Avatar
    Join Date
    Apr 2005
    Location
    Switzerland
    Posts
    20,300

    CLI command status returns waitingToPlay=>1 answer

    > I did a bit debugging with him and discovered that the status request
    > returns
    >
    >
    > Code:
    > --------------------
    > waitingToPlay => 1
    > --------------------


    The commit message for this condition says "Display can show time and
    progress-bar advancing when not (yet) playing. Added 'waitingToPlay'
    element to playerstatus response.". The check verifies whether the
    player is actually playing (streaming out data). I would assume this
    could be the case to be false with remote streaming services, or
    transcoding involved? Ask the user about what media he's using? And what
    kind of player. Maybe buffer size plays a role, too?

    --

    Michael

  3. #3
    Quote Originally Posted by mherger View Post
    >Ask the user about what media he's using? And what
    kind of player. Maybe buffer size plays a role, too?
    Sorry, forgot to mention that: From the logs it looks like he used mp3 files. Clients are SqueezePlay and a Radio. He says that playback starts "immediatly".
    But i now understand that a client may trigger the event even if it has not fully received the playlist.

    So i added a timer to the callback for the playlist loadtracks, loadalbum and addtracks events. This calls the function again after one second if the "status" request returns waitingToPlay=>1 and no playlist:

    Code:
    sub playlistCallback {
    	my $clirequest = shift;
    	my $source     = shift;
    
    	[...]
    
    	$request = Slim::Control::Request::executeRequest($client, ['status', 0 , $numberoftracks , 'tags:egu']);
    	eval{$results = $request->getResults();};
    
    	[...]
    
    	if(!exists($results->{playlist_loop}) && $results->{waitingToPlay} eq '1') {
    		$log->warn("server answer for status query is waitingToPlay. Executing playlistCallback again in one second for client:".$client);
    		Slim::Utils::Timers::setTimer( $clirequest, Time::HiRes::time() + 1, \&playlistCallback,'TIMER' );
    		return;
    	} else{
    		if($source eq 'TIMER') {
    		
    			my $cnt = Slim::Utils::Timers::killTimers( $clirequest, \&playlistCallback);
    			$log->warn("Remove playlistCallback timer for client:".$client." Timers removed:".$cnt);
    		}
    	}
    Since this is executed only when the request returns this waitingToPlay=1 value without a playlist i suspect that at least this can't break anything. Please let me know if you think otherwise.

  4. #4
    Babelfish's Best Boy mherger's Avatar
    Join Date
    Apr 2005
    Location
    Switzerland
    Posts
    20,300

    CLI command status returns waitingToPlay=>1 answer

    > Since this is executed only when the request returns this
    > waitingToPlay=1 value without a playlist i suspect that at least this
    > can't break anything. Please let me know if you think otherwise.


    I think I'd be a little more aggressively killing timers. But other then
    that: give it a try.

    --

    Michael

Posting Permissions

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