All Activity

Awesome - will test daily. I can report the current (previous) version still exhibits the issue as fully as I can attest to. Can you share an apk for the newer version you mention?

Humming along now, but the ETA is high, I assume because the "QI" TV series which is using Chromaprint (which was failing before your fix)? These episodes do have both credits and timed text subtitles In this example, the credits actually start at 29:00, but EmbyCredits says "00:27:56 / 00:298:26"

What is the path to it?

The folder "Emby" which was a top level folder on my Nas

Oh, and this might have been mentioned on another thread, but when in TV mode there's an "on page" keyboard that's awkward/slow to use. Why can't it just like everywhere else with just a regular text input box and pop up the assigned system keyboard from there? Yes, it can cover the results while typing, but the user should be able to escape out of the keyboard popup to see them and then hit a button again to pop up the keyboard for more editing if needed.

Hi, what exactly did you delete?

In a bit of a hole here. Emby was running and working fine a few hours ago. I downloaded a few plug-ins, restarted Emby and it's never come back online. After losing patience, I deleted everything from the Emby folder, uninstalled Emby, restarted the NAS and reinstalled Emby (emby-server-synology7-mono_4.9.5.0_armv7_legacy) Emby is installed on the NAS, after setting it to run, it says "manually stopped" after a few moments. Sometimes it does Run, but I can't connect to the web interface. Desperately hoping someone can help, please!

Hi, Emby doesn’t decide to delete info out images.

How have you configured your Emby user audio settings? That’s what matters more than what track is marked as default in the file.

Thanks, it seems to be working now. Thanks for the quick response!

that's a great point and something I already did, but emby decided to delete info and try to re-scrape everything. It also decided to delete a bunch of images I already had saved.

Probably not relevant: Apparently Apple OS can throttle back activity, based on battery levels that go below 80%. https://www.gadgetreview.com/the-real-battery-gate-how-to-check-if-apple-is-still-throttling-your-iphone-and-stop-it#google_vignette Also, your test media is pushing the limits of playback. I wonder if even a change in Wifi activity might trigger an transcoding for the audio. Or does the update have any default playback settings that changed, instead of keeping the previous settings? Yes, of course, there can be a code issue that needs to be corrected. It might be helpful to test less demandng fps and media bitrates to see where playback starts to work.

Scratch that, user error.

Ok Fair. Now go apologies to the poster, which post you dismantled.

Just wanted to ask about 2 part movies and how they are handled. I have a folder for Kill Bill. In the folder I have kill bill - part 1.mkv and kill bill - part 2.mkv. Only part 1 is recognized whereas on my nvidia shield shows both parts as well as my emby server does. Not sure what I’m missing

Hi Luke, It works perfectly! Thank you!

Thanks, I think this discussion has actually cleared up several things for me. First, @vdatanet was right about the terminology. I was mixing up Direct Play and Direct File Access. If Emby delivers the original media byte-for-byte unchanged over HTTP, then it is Direct Play. What I was actually referring to was Direct File Access, where the player opens the original file directly from the network share and handles its own I/O, buffering and seeking. I still prefer Direct File Access for my local Kodi/CoreELEC setup, but I understand why HTTP is the practical solution for most Emby clients. @FrostByte's information about the Shield is also interesting. So Direct File Access wasn't fundamentally impossible there — it actually existed, but changes to Shield OS made it unreliable enough that the option was eventually disabled. That answers part of my original question. @Luke, your explanation about Emby's player also corrects an assumption I had made. I wasn't aware that Emby has heavily customized ExoPlayer/Media3 and also integrated client-side FFmpeg software decoding. Since Just Player is itself based on ExoPlayer/Media3, I agree that simply blaming ExoPlayer is too simplistic. Clearly, different implementations of the same underlying framework can behave differently. However, I don't want to turn this into another round of reproducing old playback problems on my Shield. I've done that kind of testing in the past, and my current setup is deliberately configured around the solutions that work reliably for me. I'm not going to dismantle or reconfigure my working setup just to reproduce issues I've already worked around. On the Shield in the bedroom I use Emby with Just Player because that combination works for what I need there. On my main system I use Kodi/CoreELEC with Direct File Access because that gives me the playback path I want. So I'm not asking you to debug my Shield setup here. My broader point was to understand why these different playback paths behave differently and why Direct File Access disappeared from the Android TV client. I think the answers from all three of you have clarified that considerably. I may not agree with every design decision, but I understand the technical reasoning behind them much better now. Thanks for the explanations. So I think we've actually made some progress here.

I know this has been requested in the past, but it's been years (almost 7) since then, and it's not live in a usable form on Emby for Android. There's a fundamental misunderstanding on how codecs are handled and what can and can't be passed via TOSLINK, Arc or eArc. With an Emby for Android install on a TV - in this case, a Bravia x95j, Emby (correctly) sees that the TV can decode AAC audio in 2.0, 5.1, etc. What it does not see is that if the TV is set for passthrough to an audio receiver or soundbar, it CANNOT PASS AAC OVER HDMI - because AAC and HDMI do not ever work together. Then, by default, TVs will downmix this to PCM 2.0 because again - HDMI hates AAC, and Arc does not support PCM 5.1/7.1 - there just isn't enough bandwidth in TOSLINK or Arc to make it work. While eArc CAN carry pcm bitstream 5.1/7.1 - TV's will always force AAC down to PCM 2.0 to send it via passthrough on any HDMI link. There is no TV on the market that natively remixes AAC 5.1/7.1 to any type of multichannel format in order to pass it to another device. It's always remixed to PCM 2.0. Kodi has the ability to force-flag a conversion of any AAC audio to AC3 in the options - Emby's built-in option relies on a hardware detection algo that doesn't see if the codec is being sent anywhere other than the TV it's installed on. Here's the TL;DR Problem - no option to force AAC to AC3 conversion on a device with native AAC decode, but AAC can't be sent over HDMI if a receiver or soundbar is involved for the audio playback. PCM 2.0 is the result, 100% of the time. Cause - AAC doesn't play nice with HDMI, and TOSLINK/Arc don't have the bandwidth to support it in multichannel, even if they did. Emby does not consider devices down the chain that might be handling audio from the TV via Arc, eArc or Toslink - only the base hardware capabilities of the device it's installed on. Solution - instead of an "if a video uses a codec but the system Emby is installed on has incompatible hardware, force conversion to AC3" option, add an "always convert to AC3 for these codecs" option, similar to Kodi's.

Ok let me spell it out. Did you read the link to the post? Read what I have marked with red Posted July 9 New patch release - Version 4.1.4.0 Download .dll and full release notes: https://github.com/soderlund91/HomeScreenCompanion/releases/tag/v4.1.4.0 Bugfix release IMPORTANT! Minimum required Emby server v4.10.0.17 Release notes Fixes: Tagging collection: Fix issue where tagging a collection name containing a comma isn't working (Eg. "1,001 Movies to watch") Playlist: Fixed a bug where new items where added to the end of the list, now it correspond with the order of the source. Top-list: Fixed an bug with "resume playing" when switching between different versions of the movie (added ffprobe to the .strm files on creation to get playtime etc.) HomeScreenCompanion.dll 1.03 MB · 18 downloads

Thank you for making this. This is an excellent addition!

Hi, the issue is fixed with v1.1.3 https://github.com/MDBList/emby-plugin-mdblist/releases Please update and sync again. Emby.Plugin.MDBList.dll

Checked 4.10.0.31 today, same setup as before: fresh container, same synthetic sample, same probes. Nothing has moved on the tail. Every row below is 4.10.0.30 -> 4.10.0.31: - identical final segments, 6-second segments: 2 -> 2 - identical final segments, 3-second segments: 3 -> 3 - md5 of those segments: f40fe109... -> the same - last fMP4 segment, fresh sessions: no response -> no response - "FfRunException" in the server log: 0 -> 0 - ts matrix: all 200 -> all 200 - mp4 matrix, segment 221: 45-second hang -> 45-second hang The image id is different from .30, so something was built — just not this. And the .30 fix holds: FfRunException is still zero, so nothing has regressed either. The mechanism is the one from my last post: you restart ffmpeg per segment and seek to the nominal boundary with the video copied, so when the file's last keyframe falls before the penultimate segment boundary with none after it, every later run rewinds to that same keyframe and emits the same frames. The recipe for a file that reproduces it is in that post, and it takes about two minutes to build. Posting this mainly so the thread has the number for .31. Happy to test any build, and to run anything else you want against this setup.

Thanks! v2.7.1.8 installed - just restarting the server now and will report back!

No, which part do I need to read?