DefaultHttpDataSource disconnects after 20sec on chromebook

[rcvangemert]

I have 2 HP Chromebooks X2-v1 & X2-v2, both disconnect after approx 15 seconds from my app's HTTP server. If I connect VLC or my app exoplayer on an android only tablet it works OK.

Has anyone experienced something similar?

Thanks

[christosts]

I assume you are playing progressive media, like mp4 (basically not DASH or HLS). We don't set an explicit timeout on the player side when to disconnect from the server and let the underlying network library handle issues around connection timeouts/pooling/etc.

From the wording of your question, it sounds like the same behavior is happening with VLC on chromebook too, therefore this is not an ExoPlayer-specific issue, right?

[rcvangemert]

Sorry for the wording, No VLC works fine on android only tablet and android on Chromebook. Yes it's a progressive media source, See below. I also tried okhttp but exoplayer disconnects on the 2 Chromebooks I have but play OK on 2 android devices. My app server uses chunked encoding of a mpeg-ts stream.

therefore this is not an ExoPlayer-specific issue, right?

Maybe not, more Chromebook android?. I was just wondering if others have experienced this with exoplayer. Thanks, Robert private void open(final Uri uri) { if (isOpen) close(); this.uri = uri; DefaultLoadControl loadControl = new DefaultLoadControl(); RenderersFactory renderersFactory = new RenderersFactory() { @OverRide public Renderer[] createRenderers(Handler eventHandler, VideoRendererEventListener videoRendererEventListener, AudioRendererEventListener audioRendererEventListener, TextOutput textRendererOutput, MetadataOutput metadataRendererOutput) { Renderer[] renderers = new Renderer[2]; // renderers[0] = new AudioMixerRenderer(context, MediaCodecSelector.DEFAULT, audioMixer, index); renderers[0] = new MediaCodecAudioRenderer(context, MediaCodecSelector.DEFAULT, null, null, new AudioMixerSink(index, audioMixer)); renderers[1] = new MediaCodecVideoRenderer(context, MediaCodecSelector.DEFAULT, MediaCodec.VIDEO_SCALING_MODE_SCALE_TO_FIT, new Handler(), new VideoEventListener(), 0); return renderers; } }; exoPlayer = new ExoPlayer.Builder(context).setRenderersFactory(renderersFactory).setLoadControl(loadControl).build(); surfaceTexture = createSurfaceTexture(); final Surface surface = new Surface(surfaceTexture); exoPlayer.setVideoSurface(surface); MediaSource mediaSource; if (uri.toString().contains("http://")) mediaSource = new ProgressiveMediaSource.Factory(new DefaultHttpDataSource.Factory()).createMediaSource(MediaItem.fromUri(uri)); else if (uri.toString().contains("rtsp://")) mediaSource = new RtspMediaSource.Factory().createMediaSource(MediaItem.fromUri(uri)); else mediaSource = new ProgressiveMediaSource.Factory(new FileDataSource.Factory()).createMediaSource(MediaItem.fromUri(uri)); exoPlayer.setMediaSource(mediaSource); exoPlayer.addListener(new PlayerEventListener()); exoPlayer.prepare(); audioOnly = uri.toString().contains(".m4a"); isOpen = true; if (preferences.persistentTakeOptions()) restoreState(); }

…

On Wed, 11 Jan 2023, 7:09 am christosts, ***@***.***> wrote: I assume you are playing progressive media, like mp4 (basically not DASH or HLS). We don't set an explicit timeout on the player side when to disconnect from the server and let the underlying network library handle issues around connection timeouts/pooling/etc. From the wording of your question, it sounds like the same behavior is happening with VLC on chromebook too, therefore this is not an ExoPlayer-specific issue, right? — Reply to this email directly, view it on GitHub <#10906 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABGSW3E5WN33XW5JYJ2BKL3WRW6XLANCNFSM6AAAAAATS4HCAU> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[christosts]

I also tried okhttp

DefaultHttpDataSource is based on HttpUrlConnection which on Android is implemented using OkHttp. I don't know exactly how chromebooks are handling HttpUrlConnection but it might be that your tests using OkHttp are basically exercising the same code. For completeness, did you attempt repeating the test using Cronet?

In case it's helpful, we have a page about network stacks here.

There does not seem to be an actionable item here. I'll let the item open in case anyone else wants to chime in, otherwise it will auto-close (please ignore the bot's auto-replies)

[rcvangemert]

Thanks, I'll email once I find a solution.

…

On Wed, 11 Jan 2023 at 22:13, christosts ***@***.***> wrote: I also tried okhttp DefaultHttpDataSource is based on HttpUrlConnection which on Android is implemented using OkHttp. I don't know exactly how chromebooks are handling HttpUrlConnection but it might be that your tests using OkHttp are basically exercising the same code. For completeness, did you attempt repeating the test using Cronet? In case it's helpful, we have a page about network stacks here <https://exoplayer.dev/network-stacks.html>. There does not seem to be an actionable item here. I'll let the item open in case anyone else wants to chime in, otherwise it will auto-close. — Reply to this email directly, view it on GitHub <#10906 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABGSW3CQHH2TY2BDMWQPZC3WR2IUJANCNFSM6AAAAAATS4HCAU> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[google-oss-bot]

Hey @rcvangemert. We need more information to resolve this issue but there hasn't been an update in 14 weekdays. I'm marking the issue as stale and if there are no new updates in the next 7 days I will close it automatically.

If you have more information that will help us get to the bottom of this, just add a comment!

[google-oss-bot]

Since there haven't been any recent updates here, I am going to close this issue.

@rcvangemert if you're still experiencing this problem and want to continue the discussion just leave a comment here and we are happy to re-open this.