All Activity

I don't think you read the post correctly, or maybe I wasn't clear. My TV is where the Emby client is installed - and while the TV can play it out of its own speakers, it cannot (and does not) send AAC downstream to the receiver (or soundbar, or anything else). It converts the audio to PCM 2.0 and sends THAT to the receiver. The TV is silent (tv speakers are all junk - even on a $4k tv like the X95J was when it was new). IF I had installed emby onto a Roku or Nvidia shield and connected that directly to the receiver, you would be correct - but in this case, the TV IS the source, and it passes audio via ARC or TOSLINK (I've tried both) to the receiver, and TVs do not ever pass AAC in any form. Most TV's don't have passthru at all - it's part of why Sony Bravia's have been considered industry-leading for the last couple decades. You can google the specs and reasons why, but it's a hard & fast reality. TL;DR I don't use TV speakers - ever.

Thank you, will await my request to be processed /N

I moved over from Plex fairly recently and have been happy with the switch, so I want to be upfront that this post is about the one case I have found where Plex handles something better than Emby does. I am hoping it is a reasonable candidate for a client option. Setup - Emby Server 4.9.5.0 on a Synology DS1221+ - Emby for Android 3.5.55, AndroidXMedia3 1.8.0 - Reproduced on two devices: an R_volution PlayerPro 8K TV (Android TV module, Amlogic S905X4-K, Android 11) and an Nvidia Shield Pro (Android 11) - Wired gigabit throughout, media on the same NAS as the server Symptom One 4K HEVC file stutters badly on playback (Nick Matzke's Beyond The Room demo). The server reports Direct Play for stream, video and audio, and the server log shows no transcoding and no errors. Response times are 1 to 3 ms throughout. The playback info overlay shows the cause: Stuttering file Emby Clean file Plex Codec HEVC Main, Level 156 HEVC Main 10, Level 153 Bit depth 8-bit, yuv420p 10-bit Framerate 30.0003 fps 23.976 fps Bitrate 54 Mbps 75 Mbps Colour BT.709 SDR BT.2020 PQ, HDR10 Renderer Ffmpeg MediaCodec Both are Direct Play, both are TrueHD 7.1, and both were played minutes apart on the same device in the same session. Note that the file that works is the higher bitrate of the two, so this is not a delivery or bandwidth issue. The server log confirms it from the delivery side. On the working file the client held a single range request open for 116 seconds while playing steadily. On the stuttering file the client repeatedly disconnected and reopened at new byte offsets after 131 ms, 1389 ms and 110 ms, which looks like the loader restarting rather than a slow read. What I think is happening My read is that Android's MediaCodec capability query is returning no capable hardware decoder for HEVC Main profile 8-bit at 4K Level 156, so the client correctly falls back to the bundled Ffmpeg software decoder. Software HEVC decode at 4K is more than these SoCs can sustain, so it stutters. I want to be clear that I do not think the fallback logic is wrong. Respecting the platform's capability declaration is the safe behaviour, and I would rather have graceful degradation than corrupt output. The request Plex on both of these same devices plays this file without any stutter, which suggests the decoders can in fact handle the stream and the declared capability profile is simply conservative. Plex appears to hand it to hardware regardless. Would it be possible to add a client-side option along the lines of "prefer hardware decoding" or "force MediaCodec", defaulting to off, that bypasses the capability check? Users who enable it would accept the risk of artefacts or failed playback on genuinely unsupported streams, and the default behaviour would be unchanged for everyone else. HEVC Main 8-bit at 4K is admittedly an unusual encode. Nearly all my library is Main 10 and plays flawlessly. But demo clips and camera-original footage do turn up in this form, and having a way to opt into the hardware path would close the one remaining gap I have found relative to my old setup. Happy to supply the full server log, mediainfo output for both files, or overlay screenshots if any of that is useful. Thanks for the work on the Android TV client, it has otherwise been a clear step up for me.

The new version with all the fixes (2.7.2.0) is up in the catalog now.

@enterpr1seI have fixed the bug and it should no longer set a 0:00 as a time stamp. The thing that actually was wrong is that in backups i set that time stamp as an indicator of a failed detection, the plugin would later take that as an already existing time stamp and use that. I added a little block for time stamps at that point.

@RedNo7I forgot to say that the ETA is no very precise either. It calculates it based on the files that had detection run already, it the best i could do.

You fixed it apparently! Thanks

@FrostByte Yes, I remember that now. I actually downgraded my Shield to Experience 8.x back then specifically to keep Direct File Access working. As I remember it, Eric, @ebr, originally implemented the feature very quickly after a user requested it. When the newer Shield Experience changed things and the implementation needed to be adapted, he didn't want to continue maintaining it because he felt that too few users were actually using Direct File Access. Later I moved my main playback setup to the Ugoos with Kodi/CoreELEC, so Direct File Access on the Shield stopped being relevant to me. My Shield is fully updated again today. So that's an important distinction: Direct File Access wasn't abandoned because it was fundamentally impossible on the Shield. It was abandoned because maintaining it after the Shield OS changes apparently wasn't considered worthwhile for the number of users using it. Actually, it all worked perfectly back then with Direct File Access; if I hadn’t bought the Ugoos, I’d probably still be using it that way today.

The MediaSources didn't work because all scripter-X could get handed to it was the movie ID, which is apparently unique to each version (see the prior post). Fellowship has multiple versions, as correctly IDed on the interface, but the REST API only returned a single MediaSource when querying. I did end up getting everything working. I'll walk through the solutions here, but if someone wants the actual python code, let me know. To accomplish the tagging goal, I had to treat movies and TV episodes differently. Movies I tagged scripter-x to run against any item update that was a movie. I used the REST API to grab the parent of the movie instance and then grab all movies that shared the parent. This was the only way I found to grab all versions of a movie. Movies have separate instance IDs and outside of using a TheMovieDB or IMDB common ID (which I have some movies that may not match), this was the only way I found to grab all the "versions" of a movie since they since in the same folder (which is the movie parent). Episodes This was a little more straight forward since scripter-x can automatically retrieve the series, season, and episode numbers. Make a REST API query to get all episodes from a given season. Iterate through the results for all objects whose 'IndexNumber' matches the episode number (the REST API wouldn't take IndexNumber as a searchable input from my experimentation). End result is a list of all versions of that specific episode.

Funny thing, it was set to public before when this started and it still sometimes worked. I set it to private as one of the many help articles recommended, and it's still causing issues. I just swapped the laptop back to public, and still no change.

It might be worth checking your laptops network has been set to "public" instead of "private" - this is a thing that Windows Update sometimes messes with. Paul

OK if you're trying to make a fresh start then you should also delete the server data folder: Emby Server Data Folder

HI, just look in the folders next to the files.

i saw it on the server, that's why when I originally added the libraries back I first set it to only use the previous nfo files to pull info, it just didnt so I decided to allow it to scrape tmdb since it wasn't populating info and that's when it began altering the nfo files. I also added a bunch of photos to another library and then the next day half the images were just gone. I don't know what other program would have deleted those images considering emby is the only program I use to organize my media library. I also had another weird issue where when I was manually organizing my movie library, I was deleting folders that used to contain copies of movies that were in different formats in order to organize all the formats into one folder and emby (or something else) was recreating those deleted folders and then adding nfo files to em.

Zam, Double check you are naming the files according to the suggested guide. https://emby.media/support/articles/TV-Naming.html?q=FIle name https://emby.media/support/articles/Movie-Naming.html?q=FIle name If you vary from these name directions, Emby could think that a secon Rocky movie is really another version of the 1st movie and combine both together in one movie with a pull down option to go from one to another. This would result in you only seeing the first Rocky listed. The 2nd film would be combined into the first media page and you would never see it in a search or in a collection. This happens automatically if your file naming is not accurate. I didn't read everything above, but just wanted to mention this as a possible issue. Go into the media that has a page and look for the other movies showing up in a pull down option for different versions to see if you have this happening.

Same here on my LG G5 on Emby 1.0.51 unfortunately. Latest WebOS25 Update.

I Just updated Emby on my LG G5 to 1.0.51 but the problem with DTS transcoding persists. :/

Any idea where I should start looking? I have no clue what might be denying access.

Goros, My media content uses AAC audio at the highest bitrate and it always plays fine, directly to TV internal speakers using an HDMI cable. Your system has perhaps something in between like an AV amp or the connection directly to speakers or pass through to speakers, causes some issue. I don't use AC3 because going to a windows or TV web browser AC3 or EC3 audio always triggers a transcoding and AAC doesn't. Why do you think your setup has AAC connection issues and my direct from server to TV has no issue?

It does not need to change the real Media Library images (I agree that would be unworkable if so) , A case in point is iconic plugin. That applies badges visbile on android and my media library images are unaffected (I store images in my media folders fwiw and this is what i am checking when i say it doesnt change those).

Yes this is something you'll need to look at: Permission denied The server is being denied access to open the file.

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

What makes you think it deleted information? Perhaps it was just never on your server to begin with.

It shouldn't do that at all. Failed detections should not add anything. I can't replicate it but I will look into it asap!

I didn't test this function for a long time, but Kodi should automatically join the parts into one single movie.