All Activity

Yes you can cancel now. Thanks

I feel like it has to do with anytime there's a transition from HLS/AAC --> MP3 playback. (<-- or something related to contiguous but dissimilar file playback). If I may, here's a snippet from AI helping me troubleshoot this problem from a while back. I let AI ingest a portion of a log file. This is what led me to try adjusting the remote (cellular) cap, which did work to keep the problem from happening. I was using Emby Android 3.5.36 at this time (about 4 months ago or so). Would the full debug and ffmpeg logs help? The server did its job and handed off the next track correctly. The failure is on the client side — the Emby for Android app (v3.5.36) failed to start playing the new HLS stream and aborted right away. Why This Happens (Especially Remotely) HLS Transcoding Handover Issues: Common on Android when skipping tracks in playlists remotely. The app's media player (ExoPlayer) sometimes chokes on starting the next transcoded segment, especially with FLAC sources or bitrate mismatches. Remote + Low Bitrate Cap: Your setup forces transcoding (good for bandwidth, but fragile for seamless playlist playback). App Version: 3.5.36 is fairly recent, but similar issues have been reported with FLAC/remote skips. Quick Things to Try Raise the bitrate limit on the Android app (under Playback → Quality or Video Quality settings) to allow Direct Play/Stream for more files. Test if it reduces transcoding. Force lower quality or test with an all-MP3 playlist to see if FLAC sources are the trigger. Don't skip manually — let it play through naturally and see if auto-advance fails the same way. Local network test: Play the same playlist on Wi-Fi (same LAN). If it works, confirms remote/transcoding sensitivity. Update/reinstall: Ensure server is latest; try clearing app cache or reinstalling the Android app. Next Steps for Logs Enable full debug on both server and Android app, reproduce, and grab: The matching ffmpeg transcode log for the ABBA track (should show what happened during that brief attempt). Android app debug log (via the app's "Send log" feature) — this will likely show ExoPlayer errors.

I think this has come to pass with: Thanks!

This. I assumed it meant there was a problem the first time I saw it. It's just an annoyance, and all it does is give me a button I might accidentally click that will cancel the connection. Make it at least 5 seconds.

embyserver (1).txt

No. The first time I started the app, after updating, I got the java io error - see attached. The 2nd time I opened it, it took around 60 seconds to get to the home screen. Log attached for that also. emby_android_1787934218575.txt emby_android_1787934380047.txt

Btw, with the Android TV 2.1.55g app, playing the m4a files gives no audio, though it continues to play. It has the following in the Dashboard: Stream M4A (713 kbps) -> Direct Play Audio ALAC stereo (Default) -> Direct Play

that's great ...look forward to testing thank you for taking on this project I have been using Infuse for the past couple years and it works great, but to have a media player for the apple TV that is designed to get the best out of emby (jellyfin) is awesome, i have retired both of my nvidia shields and exclusively use Apple tv

For playback with both apps, it shows the following for aif files: Stream AIFF (2 mbps) → Direct Play Audio PCM_S24BE stereo → Direct Play Android 3.5.36 does NOT play the file, while Android TV 2.1.55g DOES play the file.

No – I’ve just got a better player. The Ugoos AM6b Plus. It plays Dolby Vision 7 FEL perfectly with CoreELEC. No Android app can hold a candle to it.

@TeddyknuddelI guess you have issues with Emby. Here is how to report a problem

That's correct. In the past when the Google screensaver kicked in, it would show the song name at the bottom left corner while Emby was playing.

Hi, we are working on improving this. Thanks.

So you're referring to a system screensaver and not an Emby one?

OK we are looking into it. Thanks.

I don't have an update on remembering playback speed, but the button has been made quicker to get to in some layouts.

Btw, I only have a very few songs in aif. Maybe I should just convert it?

you could check the server dashboard during the aif playback.

Hi there, please attach the Emby server log from when the problem occurred: How to Report a Problem Thanks!

Hi, I think we need to look at improving resiliency to network disruptions. I think it has more to do with that than transcoding vs not transcoding.

Not sure what you mean. What should I look for?

HI, yes I think the tv app is probably having the aif transcode, right?

Im already using Emby 4.10.0.28 beta. The only difference to previous versions is that I now get a pop-up error message.

@Grumpy1 When you asked what triggers Dolby Vision, the honest answer was that Atrium didn't signal it, and I said I wouldn't put a date on it: I don't own a Dolby Vision TV, and shipping signalling I can't test is how you end up with a red screen in someone else's living room. That part hasn't changed. The rest has: it's written, and version 1.4 is in review now. None of it was deduced from the spec — it's copied from a real master playlist for the same file. The base-layer codec stays where it is and the Dolby Vision goes beside it, in SUPPLEMENTAL-CODECS. Atrium copies the DV configuration box out of your file byte for byte and derives the tag from that box, not from what any server claims about the file. Three things make it safe to send out untested: - It only happens if your TV announces Dolby Vision. On any other TV the output is byte for byte what it was before, and there's a test that keeps it that way. - If playback fails with DV signalled, the app redoes it without. You keep on-device playback and you keep HDR10 — the worst case is a blink, not a broken picture. - The new Playback Information screen says, in words, what actually happened. So here's the favour, whenever 1.4 reaches you. Play one of your Dolby Vision files, open Settings > Playback Information, and read the Dolby Vision line. It says one of: - "in the file and signalled to the TV" — this is the one I need to hear about. Does your TV actually switch into Dolby Vision, with its own indicator lit? - "in the file, not signalled — this TV doesn't announce Dolby Vision" - "in the file, not signalled — its base layer is neither HDR10 nor HLG" — a file I deliberately don't tag, because the servers don't tag those either - "signalled, then withdrawn" — it was tried and playback failed. I'd very much like to see this one, and I'd like to see it before anyone else does. Two kinds of file won't get you any of that, so you don't waste an evening on them: profile 5 (the ones with no HDR10 base layer) now go to the server on purpose — prepared on the device, their colours came out wrong — and dual-layer files aren't tagged. A photo of that screen is worth more than anything I can measure here, and both answers are useful: "it lit up" closes this, "it didn't" tells me where to look next. Post it here. And the other half of what you asked for is in the same version: the details page now shows resolution and dynamic range, with Dolby Vision taking precedence over its own base layer. I'll post here when it's out.

@Luke