From #4562: Disable player stream preloading only if the current stream is going to be replaced for sure (see this). equals() was implemented for PlayQueueItems, so that (only) the url is compared when checking them.
We don't need to call ``updateRelativeTimeViews`` when the activity is paused, because the user likely won't notice it.
Despite that onResume already calls ``updateRelativeTimeViews`` so there is no need to do that twice.
Playing a video in VideoDetailFragment and rotating the screen to landscape (back and forth more often)
can trigger this error message. Especially if rotation for whatever reason takes long or
playing a high resolution (1080p) video.
The underlying logcat error messages:
05-12 16:38:38.251 24920 26037 E Surface : getSlotFromBufferLocked: unknown buffer: 0x923fc810
05-12 16:38:38.251 24920 26037 W ACodec : [OMX.qcom.video.decoder.avc] can not return buffer 35 to native window
The problem is that that Exoplayer is trying to write to our -- during rotation -- no longer existant
(VideoDetailFragment) SurfaceView.
Solution:
Implementing SurfaceHolder.Callback and using DummySurface we can now handle the lifecycle of the Surface.
How?: In case we are no longer able to write to the Surface eg. through rotation/putting in
background we can set a DummySurface. Although it only works on API >= 23.
Result: we get a little video interruption (audio is still fine) but we won't get the
'Unrecoverable player error occurred' error message.
This implementation is based on and more background information:
'ExoPlayer stuck in buffering after re-adding the surface view a few time 2703'
-> exoplayer fix suggestion link
https://github.com/google/ExoPlayer/issues/2703#issuecomment-300599981
- bugfix: have ServiceConnection created only once!
- select the context within the PlayerHolder to start, stop, bind or unbind the service
-> we have to make sure the Service is started AND stopped within the same context
-> so let PlayerHolder be the one to select the context
- remove removeListener() and replace the call with setListener(null)
- Compatibility: use ContextCompat.startForegroundService instead of startService()
instead use service.stopService() which inturn calls stopSelf() and
triggers hopefully onDestroy() to be called. Eventually we have to make
sure that all ServiceConnections are closed to successfully stop the service
now!
Cleanup within stopService() and not only onDestroy()
So we make sure that all listeners can react to onServiceStopped()
and close their ServiceConnections. Afterwards the android framework
is ready to stop the Service.
It seems due to #6394 updating the FragmentX library there was a
change to the order of lifecycle calls, as such onResume() was no longer
before onCreateOptionsMenu() creating a null pointer exception when
using service in onCreateOptionsMenu() as it is only set in onResume().
By moving the initialization of service to onStart() which still happens
before onCreateOptionsMenu() this crash can be avoided. This commit also
adds a check for a null service to prevent future crashes for similar
issues.
System is now not restarted with `System.exit(0)`.
Instead it is done properly by finishing the activity and restarting the activity. This allows preference changes which are queued up asynchronously through `apply` to be applied.
