All Activity

so once you see the emby logo, then it's fast?

Well you've seen the logs. Is there nothing in there you can see as to why it takes so long. Can you add more logging? The ATV app loads in seconds every time.

The actual connection speed to server is no different. He's reporting 30-40 seconds of a blank screen before he sees anything. That tells me we need to look at what happens before the UI loads and make sure we're not waiting on something to complete before showing the user interface.

'Here's the log file. I tuned to CNBC at 12:50 pm PDT / 3:50 EDT. Only one user (Admin). It took 2-3 minutes for the audio to resolve itself. For the first 2 minutes audio consists of periods of normal sound followed by 2-3 seconds of no sound, repeating every 15 seconds or so. embyserver.txt

Emby Server version: 4.9.5.0 (Linux) Platform: TerraMaster NAS, Ubuntu 22.04 base, kernel 6.12.63 Hardware: Intel Alder Lake-N (UHD Graphics), driver iHD 25.2.4 Device: /dev/dri/renderD128 Summary: Hardware acceleration is enabled (EnableHardwareEncoding: true, HardwareAccelerationType: vaapi), and the Hardware Detection scheduled task correctly finds the GPU adapter every time it runs. However, CodecManager's final CodecList always comes back empty for hardware encoders — only software (libx264) ever gets registered, forcing every transcode into full CPU software encoding (250%+ CPU for a single 1080p stream). Steps I've taken to rule out anything on my end: Confirmed a manual ffmpeg -hwaccel vaapi -vaapi_device /dev/dri/renderD128 -c:v h264_vaapi encode succeeds completely outside Emby — hardware and driver both work fine. Confirmed the emby user is in the render group and /dev/dri/renderD128 has correct permissions. Ran Emby's own bundled ffdetect tool manually — as the emby user, with Emby's exact environment variables (LD_LIBRARY_PATH, LIBVA_DRIVERS_PATH) — using the exact command Emby itself runs (ffdetect ... vaencdec -print_format json). This returns a full, valid Encoders array including H264_MAIN with real capabilities (MaxWidth 4096, RateControl 3294, etc.) and no errors. Server logs confirm VaapiCodecProvider successfully detects the adapter (Adapter #0: 'Alder Lake-N UHD Graphics') on every Hardware Detection run. Immediately after that same detection run, the log shows CodecManager: CodecList: with nothing following it — completely empty. Re-triggering Hardware Detection after fixing permissions doesn't change the outcome. Already on the latest stable version (4.9.5.0) — this isn't fixed by updating. Conclusion: Detection genuinely succeeds and returns valid hardware encoder capability data, but something in how CodecManager parses/consumes VaapiCodecProvider's output is failing silently for this driver version, so the working hardware encoder never gets registered for actual use. Happy to provide full logs, the raw ffdetect JSON output, or test any patch/beta build if that would help track this down.

Just wanted some clarification on Emby clients/apps naming and issue reporting. Emby Windows/XBox App - Windows Store application, v2.317.0 Emby Web App (Legacy) - Emby Theater 3.0.20/21 with resources at https://tv.emby.media, v26.0.19 Emby Web Client - Emby Server based client, v4.9.5.0 Based on the reported information that would make this a Emby Server/Client issue, correct?

Ditto, see no difference in connection speeds between UA and ATV apps.

It doesn't really matter because everyone gets the message no matter the speed they connect. My connection is about the same as with the AndroidTV app and I get it. It just needs to be turned off for some. However yes, it would be great if they could figure out why yours is so slow compared to ATV.

It's probably best to subscribe to the Linux Beta forum. Most likely it will be just an update to the DEB package for ARM (which can be installed on the RPi), not a specific RPi package anymore.

sorry, I misread you question.

Make the connection faster, like it is with the ATV app.

I’m not buying one that’s what I am currently using for my Emby server

I think it's Emby for Android 3.5.55.

Two days ago - on Monday

Hi GrimReaper, Thankyou for taking the time to explain, I now understand. I will look at Embyicons. Cheers Jak

HI, what version number of the app are you running?

And you're testing by deleting something in a long list?

Okay, I recently, after years of refusing to switch from the Emby for Android TV app to the standard Android app (just on Google TV).. I love it. Here lies my issue. Within the last 24 hours, a function is no longer functional and I don't know if it was never supposed to work that way (if not, it should be), it's a bug or user error on my end.. but up until last night (possibly due to the update), when using the playlist function, the channel button on the remote was effectively a redundant skip for those of us whose remotes don't have a hardwired skip button on our remotes and it was AMAZING. Is there a way of getting this functionality back? (Thanks in advance either way to all the devs.)

OK, when did you update?

@malghanatracking as a separate feature request. Thanks.

Hi, we are looking into it. Thanks.

Hi, this is not stored anywhere, so you'd have to roll your own.

Hi, we are still looking into it. Thanks.

Hi @Luke: by any chance do you have some idea for this issue?

That's awesome! I'm really excited for this update. Is there any way I can track progress or get notified when this change is implemented? I'd also be willing to test the feature on actual hardware if that's helpful at all