Skip to content

Fix voice command exception and improve behavior

Robert Stone requested to merge rhstone/vlc-android:fix-voice-command-threading into master

Description

This MR cleans up threading behavior from voice search and also changes the behavior to return the combined results from certain voice queries. Currently, invoking "Play artist X" will start playback of the first album from the artist, rather than enqueuing all the albums. After this fix the search function will queue all albums from artist X. Additionally, "Play Something" now re-sorts the results to match the android auto sort order, and enables shuffle by default. Other queries will disable shuffle mode and play in order. The playback state now also passes the currently enabled actions for consistency.

Motivation and Context

I observed an exception during integration with Google Driving Mode when the player was started via voice command. The lazy associated with player speed hit an assert which flagged the caller as being off the main thread. After investigating, I determined the issue should be resolved, and a few improvements were due at the same time.

Original exception:

AndroidRuntime: FATAL EXCEPTION: DefaultDispatcher-worker-2 @coroutine#22
AndroidRuntime: Process: org.videolan.vlc.debug, PID: 31271
AndroidRuntime: java.lang.IllegalStateException: Cannot invoke setValue on a background thread
AndroidRuntime: 	at androidx.lifecycle.LiveData.assertMainThread(LiveData.java:487)
AndroidRuntime: 	at androidx.lifecycle.LiveData.setValue(LiveData.java:306)
AndroidRuntime: 	at androidx.lifecycle.MutableLiveData.setValue(MutableLiveData.java:50)
AndroidRuntime: 	at org.videolan.vlc.media.PlayerController$speed$2.invoke(PlayerController.kt:37)
AndroidRuntime: 	at org.videolan.vlc.media.PlayerController$speed$2.invoke(PlayerController.kt:30)
AndroidRuntime: 	at kotlin.UnsafeLazyImpl.getValue(Lazy.kt:81)
AndroidRuntime: 	at org.videolan.vlc.media.PlayerController.getSpeed(Unknown Source:2)
AndroidRuntime: 	at org.videolan.vlc.PlaybackService.addCustomSpeedActions(PlaybackService.kt:1064)
AndroidRuntime: 	at org.videolan.vlc.PlaybackService.publishState(PlaybackService.kt:1025)
AndroidRuntime: 	at org.videolan.vlc.PlaybackService.publishState$default(PlaybackService.kt:971)
AndroidRuntime: 	at org.videolan.vlc.PlaybackService.shuffle(PlaybackService.kt:1100)
AndroidRuntime: 	at org.videolan.vlc.MediaSessionCallback$onPlayFromSearch$1.invokeSuspend(MediaSessionCallback.k
AndroidRuntime: 	at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)
AndroidRuntime: 	at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:106)
AndroidRuntime: 	at kotlinx.coroutines.scheduling.CoroutineScheduler.runSafely(CoroutineScheduler.kt:571)
AndroidRuntime: 	at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.executeTask(CoroutineScheduler.kt:738
AndroidRuntime: 	at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.runWorker(CoroutineScheduler.kt:678)
AndroidRuntime: 	at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.run(CoroutineScheduler.kt:665)

How Has This Been Tested?

Debugging confirmed playbackService is now called on the main thread. Tested with various voice queries:

  • Play Something
  • Play Artist X
  • Play Album X
  • Play Song X

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • Enhancement (non-breaking change which cleans up / improves existing functionality)

Checklist

  • I have read the CONTRIBUTING section of the README document.

Merge request reports

VideoLAN code repository instance