All Activity

Are there any additional logs I can provide to assist?

My excuses. I misunderstood that. I saw Audio transcode in the UI. Transcode is not the same as remuxing. I have a Synology 920+ that is capable of doing just that without a sweat

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

I think @sa2000has observed this before and we are working on chasing it down. Thanks.

I'm going back to what I read on the nVidia forum that the Shield can only convert to PCM 2.0 because it doesn't have any other encoder

You're probably better off using a home videos library for that. Then it won't matter how they are named.

Maybe that's why it sounds better to you

I also noticed that it's DD+ and not DD like the rest of the apps

Will this plugin arrive to official Emby plugin catalogue?

Why? Is your server that underpowered to remux audio?

@ebrCould you comment here please.

For this particular use-case, it's a collection of YouTube videos that are required to be downloaded by an internal identifier. This is basically any string of alphanumeric characters at the end, ie -- [KPY3L9Daxc4] I can tell the developer of the app what particular strings to avoid, is it strictly S followed by a number? That said, is simply having a title of "May 1st 2023" going to cause this issue? A lot of the videos need to maintain their date in the title, but they don't need the alphanumeric section.

The exact same thing that happens with every other option. The server would convert the media, then transfer it to the device, then after a few short seconds the file would disappear from the device. The emby for android log I provided earlier was from where I just used the download arrow option.

Update — version 1.1.0 is out: Embeat is now native on iPad Quick recap for anyone landing on this thread for the first time: Embeat is a native iOS music-only player for Emby — gapless FLAC/ALAC direct play, offline downloads, DLNA, playlist management. €9.99/year, one month free. It talks straight to your server, with nothing of mine in the middle. Apple approved 1.1.0 today and it's rolling out now. On iPad (the point of this release) - A sidebar instead of the tab bar: Home, Artists, Albums, Songs, Genres and Playlists, always in view. - Two panes when there's room — the list on the left, the detail on the right, without losing your place. - Two-column player, with the full editable queue beside it. - Search shows the results and the selected item at the same time. - Rotating the device keeps both your selection and your place in the list. And for everyone, iPhone included - Tapping a song in Songs, on Home or in search now plays it, with the queue taken from that same list. - Shuffle in the playlist detail and in Songs now runs across the whole library rather than just what's loaded. - New playlists appear under Playlists without pulling to refresh. - Gone: the double back arrow in Genres and Playlists. - Home sections no longer disappear after you reorder them. Requirements are unchanged: iPhone or iPad, iOS/iPadOS 18.4 or later. What's next I had the audio engine independently audited last week and it turned up a handful of genuine playback bugs: a brief dropout at the start of a track, failures on cellular data, opens that never completed, a pause that could get stuck on "loading", and FLAC seeking that made the progress bar lie. Those are fixed and going through TestFlight now, so the next update is mostly playback reliability. Also worth saying here, since it's the thing people have asked for most since launch: Apple has granted me the CarPlay entitlement, so it's no longer blocked on their side. Nothing is built yet and I'm not going to promise a date, but it's coming. Android is still in development and not out. App Store: https://apps.apple.com/app/embeat/id6788410988 Site: https://www.embeat.media Feedback and bug reports: here or joan@vdata.net — I read everything. Thanks again to everyone who tried it and wrote in; several of the iPhone fixes above came straight from this thread.

I upgrade to the latest release and I see in the service startup: Aug 01 11:13:33 Emby sh[1632]: /bin/sh: /opt/emby-server/lib/libc.so.6: version `GLIBC_2.38' not found (required by /bin/sh) Aug 01 11:13:33 Emby sh[1632]: /bin/sh: /opt/emby-server/lib/libc.so.6: version `GLIBC_2.33' not found (required by /bin/sh) Aug 01 11:13:33 Emby sh[1632]: /bin/sh: /opt/emby-server/lib/libc.so.6: version `GLIBC_2.34' not found (required by /bin/sh) And of course the service fails to start. This is on Debian 6.12.94-1 (2026-06-20) x86_64 (not docker) I saw this trying to upgrade from 4.9.3.0 to 4.9.4.0 and to 4.9.5.0

How are your files named and organized?

Right now there are no plans to remove but the list of features that don’t work with it is likely to grow over time.

Hi, we might be able to add this to CarPlay but the lock screen is an Apple UI that we can’t control.

Hi there, let's look at an example. Please attach the information requested in how to report a media playback issue. Thanks!

Something still isn't making sense. You imply if 'default' pref is off, then the device decides. But in my case the AC3 track is supported. Thanks for the info - I learned some things. I can't explain what happened and probably isn't worth chasing in this case. I'll have to monitor.

This: If you always want the "default" to play you would select that option. However, that could cause remuxing/transcoding when it isn't strictly necessary. In the above screenshot, the device probably doesn't directly support the audio codec of the first track so it selected the second one to direct play.

Exactly what happened when you tried that?

The output steam 1:1 is the subtitles. 8.464MB buffer. There are 3 subtitles muxing into this space from your log. If each takes up the maximum it would equal 12 which exceeds the buffer. Not sure if that is what this means the buffer size is for all the subtitles combined or just the 1. But the issue comes down to the subtitles sidedata being too large. If you remove some of those subtitles that will never get used it might make it easier to play that item. ffmpeg allows the flag -max_muxing_queue_size to change the queue size larger. But that is at the cost of memory leaking. The main reason that error comes up is to prevent memory leaks so ffmpeg crashes rather than continue out of bounds. This is happening for a reason. Maybe @softworkzknows best?

You mean this?

We already have the option to not record episodes that are already in the library.