All Activity

You can also use TimeMarkEdit to do this.

I would rerun the affected episodes / tv shows.

Unfortunately the latest release for LG v1.0.51 has not fixed the issue. Videos will not start from the beginning with the 5.1 audio track selected (2nd audio track in video file). This also often happens with stereo AC-3 audio tracks. Starting with audio track 1 (AAC stereo) and then pausing after a couple of seconds, then selecting the 2nd audio track (5.1 ac-3) and then resuming playback works. So Emby on LG will play the 5.1 audio, just not from the very beginning of the video.

I have been using the android app for over a week now. Works great. I have all my arr stack added running through tailscale with zero issues.

Sorry, one more question! For the videos that were processed before updating to v2.7.2.0 and already have the credit start time set to 0:00, how can I remove or clear those timestamps? Even after updating to v2.7.2.0, SenPlayer is still reading 0:00 as the credit start time for those previously processed files.

@ebr Fair point regarding the permission. If Android/Google Play exposes that permission in the store listing regardless of when it is requested, then my assumption about requesting it only when enabling Direct File Access was wrong. But I think we're mixing two different issues here. Kodi on Android can access SMB shares directly and play media from smb:// paths. I use exactly that myself, both standalone and together with Emby. So are you saying that Emby's implementation of Direct File Access specifically requires this additional Android permission, or that direct SMB access itself requires it? Because those are two very different things. As for proving a quality advantage: no. If HTTP Direct Play and SMB deliver exactly the same original data to the same decoder, there is obviously no inherent difference in picture or sound quality. I've already corrected myself on that point. But I don't understand why Direct File Access has to prove superior picture quality or raw efficiency in order to have a benefit. With Direct File Access, the player accesses the original file on the SMB share directly and handles the file I/O, seeking and buffering itself. The Emby Server doesn't need to be in the media data path. That's the architecture I prefer for local playback, and it's exactly how I use Emby with Kodi/CoreELEC today. Kodi has supported direct SMB access for years. It works. Emby itself also supported Direct File Access on the Shield in the past — I used it myself and even downgraded my Shield to Experience 8.x specifically to retain it. So my question is quite simple: if Kodi can implement and maintain direct SMB file access on Android, why is the same concept considered to have such a “debatable” benefit in an Emby client? I fully accept that most Emby users don't need it. But “most users don't need it” and “there is no benefit” are two entirely different statements.

@ebr

Thanks! May I ask one quick question regarding the settings? The description says the plugin will check TheIntroDB before processing the video. Does this check happen before or after it verifies whether the file is a .strm file? If it can lookup TheIntroDB prior to checking for .strm files, that would be super helpful!

Setup a webhook that subtracts screen time that my kids earned and is recorded on the site.

v2.7.2.0 still running after starting on a schedule, thanks for those fixes!

Hi! Yes sir, it has been processed and approved Thanks! -N

That is also incorrect. How the file was delivered would have had zero effect on this issue (the one this thread is actually about).

That's not how it works. Part of the changes made by Android are that the store listing calls out certain sets of permissions in the store listing making them look dangerous. Can you provide a specific, detailed example proving any quality or efficiency gain by using SMB file access instead of HTTP?

Hi. Your server is running on an Android device?

You don't want to do that. The network is in your home and should be Private. Public networks have different much more strict firewall rules.

I mean, I’m pretty sure channel changing used to be faster before Emby force enabled live rewind.

Okay, interesting. Any way I can reset them? Some just are called "trailer".

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

Hi, did you find any?

@MrGileshas this helped?

It is working for me but they are certainly not making it easy.

@ebrI’d already written that: And I can say with certainty that my proposed solution – Direct File Access – would be the answer, and not just for this particular problem. And for many others. Yes, I keep making things difficult. Because I don’t see why your personal assessment of what is or isn’t worthwhile should be the be-all and end-all. But please, stick to the right thread

I don’t use android only an iPhone. But some bad news, trailers no longer play on my iPhone, it opens a YouTube screen with background and a play icon but it can’t be selected and doesn’t play. @Luketagging you on the above. Damn YouTube!

@ebrthanks, Eric. That is pretty much how I remembered it. But this is also exactly the part of Emby's approach that I find frustrating. Direct File Access worked perfectly well for me on the Shield. I even downgraded to Experience 8.x specifically to keep using it. It wasn't removed because the feature itself didn't work or because the Shield was incapable of doing it. Android changed, the implementation would have needed to be adapted, and Emby decided that the number of users wasn't worth the effort. I can understand the development-effort argument. What I find much harder to understand is the permission argument. If Direct File Access is an optional feature, then surely the additional permission can also be requested only when a user explicitly enables that feature. Users who don't need it never have to see or grant it. Saying that such a permission might scare users away therefore seems like a rather weak reason to remove a useful advanced feature for the users who actually want it. And there is a broader issue here. If every advanced feature is judged mainly by how many users need it, then power users will almost inevitably lose features over time. Direct File Access was never going to be something the average Emby user needed — but for the people with a proper local media setup, that was precisely the point of it. Ironically, I solved the problem by buying a Ugoos and moving my main playback to Kodi/CoreELEC. There I get Direct File Access and the control over local playback that I wanted in the first place. So yes, I understand why Emby made the decision. I just don't think “only a few users need it” automatically makes it a good decision. Sometimes the features used by relatively few people are exactly the features that distinguish a powerful media platform from just another streaming client.

How does the Android app compare in this regard?