[vlc-commits] [Git][videolan/vlc][3.0.x] 2 commits: control: dbus: emit events properly on input change
Felix Paul Kühne (@fkuehne)
gitlab at videolan.org
Sun Nov 27 20:41:34 UTC 2022
Felix Paul Kühne pushed to branch 3.0.x at VideoLAN / VLC
Commits:
1c037bc6 by Marvin Scholz at 2022-11-27T20:26:16+00:00
control: dbus: emit events properly on input change
The can-seek and can-pause variables could end up
not being set, as the callback events are not reliably
fired in case the variables changed before the callbacks
are attached.
Additionally we need to report the playback status properly
whenever a new item starts playing.
Fix #24699
- - - - -
8bf90465 by Marvin Scholz at 2022-11-27T20:26:16+00:00
control: dbus: emit CanPlay consistently
When VLC was launched from a file, the handling for playlist
change events was not sufficient as in case of starting with
a file, we could miss the event and never report CanPlay.
When playing a file from a service discovery, like our Lua
web parser scripts, this logic was flawed too, as the playlist
would always be "empty" even though we are clearly currently
paused on an input. To fix that, check if CanPlay disagrees
with reality when we get an input change and emit CanPlay.
There is no check added in the item append/delete sections,
so currently once an item from an SD is played, even when
the user has switched back to the main playlist, the status
would still be CanPlay until and item is added or removed
in the "main" playlist. However this exactly matches how the
Qt interface behaves, so I've left this behavior as-is for
consistency with the interface.
Fix #21419
Fix #22785
- - - - -
1 changed file:
- modules/control/dbus/dbus.c
Changes:
=====================================
modules/control/dbus/dbus.c
=====================================
@@ -541,14 +541,46 @@ static void ProcessEvents( intf_thread_t *p_intf,
switch( p_events[i]->signal )
{
case SIGNAL_ITEM_CURRENT:
+ {
TrackChange( p_intf );
+ // Update status when new item starts playing
+ // Just relying on the variables change callbacks is not enough
+ // as by the time the callbacks are attached, we might already
+ // have missed a change, so we need to query and set the initial
+ // values reliably here.
+ vlc_dictionary_insert( &player_properties, "PlaybackStatus", NULL );
+ input_thread_t *p_input = pl_CurrentInput( p_intf );
+ if( p_input )
+ {
+ if ( var_GetBool( p_input, "can-pause" ) )
+ vlc_dictionary_insert( &player_properties, "CanPause", NULL );
+ if ( var_GetBool( p_input, "can-seek" ) )
+ vlc_dictionary_insert( &player_properties, "CanSeek", NULL );
+
+ // If VLC is started from a file (double-clicking or specifying on CLI)
+ // there is a chance that we miss the initial SIGNAL_PLAYLIST_ITEM_APPEND
+ // event, resulting in CanPlay never being signalled.
+ // However it is not enough to check once this module is loaded, as
+ // when items from the non-main playlist (like Lua discoveries) are
+ // played, CanPlay would incorrectly be false too, even though we
+ // have a current item that can be resumed.
+ if ( !p_intf->p_sys->b_can_play )
+ {
+ p_intf->p_sys->b_can_play = 1;
+ vlc_dictionary_insert( &player_properties, "CanPlay", NULL );
+ }
+
+ vlc_object_release( p_input );
+ }
+
// rate depends on current item
if( !vlc_dictionary_has_key( &player_properties, "Rate" ) )
vlc_dictionary_insert( &player_properties, "Rate", NULL );
vlc_dictionary_insert( &player_properties, "Metadata", NULL );
break;
+ }
case SIGNAL_PLAYLIST_ITEM_APPEND:
case SIGNAL_PLAYLIST_ITEM_DELETED:
{
View it on GitLab: https://code.videolan.org/videolan/vlc/-/compare/94035013a041e1e2590059e8801f2b39c025146a...8bf904652304e9563d49a98d418e71e59bf4581e
--
View it on GitLab: https://code.videolan.org/videolan/vlc/-/compare/94035013a041e1e2590059e8801f2b39c025146a...8bf904652304e9563d49a98d418e71e59bf4581e
You're receiving this email because of your account on code.videolan.org.
VideoLAN code repository instance
More information about the vlc-commits
mailing list