All Activity

How does 4.10.0.22 compare?

I know this is a few years old, but this is still an issue. I got back from a trip a few days ago and watched a few things on the plane. It's been 3 days since I've gotten home, and it has definitely "synced" because it has downloaded new episodes during that time. For the things I watched on the plane, when I go to the episodes through the "Downloads" section on the iPad app they show as having been played. But if I go to the episodes otherwise (via TV Shows, or "Continue Watching", or whatever), they show as not played. So the played status is clearly not syncing, while other things (new episodes) are. I don't even know how to debug this sort of thing.

I've got a similar setup, using a tv-show library for content that isn't technically tv-shows, and the most reliable way to stop emby from interpreting a year as a season and episode is to put it in parentheses.

Alternative icons idea. I like using circular flag icons for audio.

New build: ROMote 1.0.0.38 (attached). Here's what's changed since the 1.0.0.34 I posted earlier. New systems Added Atari 5200, Atari Jaguar, Sega 32X, Sega CD, Sega Saturn, and Arcade - on top of everything already supported. A couple of notes: - Sega CD, Sega Saturn and Atari 5200 need a BIOS. Use the "Set up BIOS folders" button in ROMote settings; it now lists them and tells you exactly which file each one wants. - Arcade uses EmulatorJS's FBNeo core, so the romsets need to be FBNeo/FBAlpha-compatible (drop them as .zip in an "Arcade" or "MAME" folder). Saturn is also demanding in the browser, so expect it to lean on a decent device. Also broadened file-extension recognition on existing systems (e.g. SNES .swc/.fig, Genesis .mdx), so more of the sets people already have get picked up. Zipped ROMs ROMote now reads zipped cartridge ROMs (.zip / .7z) - EmulatorJS unzips them in the browser, so you don't have to extract your sets first. It reads the console from the folder the archive is in (e.g. a SNES folder), and for a plain .zip it can also read it from the ROM inside. Controls fix (phones/tablets) Fixed the double set of on-screen controls in landscape. EmulatorJS was drawing its own gamepad on top of ROMote's; that's now hidden, so you only get ROMote's per-console controls, and "Hide controls" hides the only set. Faster scanning for large libraries Big libraries scan a lot faster now. Metadata lookups no longer stall the scan on a slow or missing game, and games with no box art aren't re-checked on every scan. Tip for very large libraries: if a first scan is crawling, you can temporarily clear the ScreenScraper user/password in settings to import everything quickly (art then fills in from a faster source), and add your ScreenScraper account back afterward for richer art. Updating Stop Emby, replace ROMote.dll with the attached one, start Emby again. No settings changes needed. (Heads up: this is still a time-limited beta build - it stops after Aug 29, 2026, and I'll keep posting fresh builds.) As always, feedback and bug reports are very welcome - thanks to everyone testing. ROMote.dll

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.