All Activity

Inside the log folder...

Yes, and I have stated WHERE the file is located in logs directory. The folks who are trying to help are looking for the EmbyServer.txt file (3rd time I have said this).

I informed you that I found the location of the folder.

Hi. Did you read this...?

The EmbyServer.txt file that you indicated you found in your previous post.

The new app does allow mpv.dll updates in the same way as legacy, yes the directory is more difficult to access but not impossible. I updated it 2 days ago with the lastest mpv build. Softworkz can probably comment on the restricted usage.

If I knew exactly what to post, I would have. I am here to learn and to understand. What is exactly needed from the Windows Emby-Server program log?

So are you going to post it to allow the knowledge base to look at your logs and assist? That is the next step to help. Your asking to have this issue "resolved in the easiest and most efficient way" yet did not post the file those that can help were expecting. Please post the EmberServer.txt log file in the most easiest, efficient, quickest manner possible for next steps to be able to be taken to assist.

Emby suddenly stopped working today and normally if i cant connect to emby server locally or externally i restart my Asustor nas and its working again,but not this time. I have restarted my server and router several times and nothing helping with the issue. My asustor working fine,i can connect to all my hard disk, also i have plex on the same server and it working fine. i use to use plax until i found that Emby is better some time ago. embyserver.txt

Resolve this in the easiest and most efficient way possible, please.

Diagnostic Options are reverted to default after restarting the server. What do you see when it's set to Advanced?

Well, no, it won't. Putting the web URL in there does nothing. Is a normal user somehow supposed to find out the stream video url?

From my experience, I'm almost certain it's a proxy/cloudflare issue

@EigeplackterI already double checked all settings - but thanks for trying, it's appreciated. "Enable Hardware Accelerated Tone Mapping" is enabled and "Enable hardware acceleration when available" is set to "Yes" (I also tried setting it to "Advanced" with multiple combinations with no luck). The "Parameter Adjustment" fields in Diagnostics seem to always be empty after a restart; I double checked that I pressed and also got the "Setting saved." message, so I don't know why it's not saving. With that said, it still didn't use hardware accelerated transcoding when the parameters were set (changed tab, changed back to Diagnostics, pressed ctrl + f5 to confirm setting was saved)

That is not actually true. The ET "legacy" version (not the Windows App Store version) is still supported and actively updated through a web content server. The ET "legacy" app is basically a container app that runs on Electron and js. It also contains the MPV lib which supports native movie playback and enables ET to render it's OSD controls on top of the MPV rendered final image which give a seamless playback experience. Updates to the ET "legacy" app only update Electron, local js scripts, mpv-1.dll and any external apps like RefreshRate.exe. All other app functionality is driven by the external web content (html, css, js, json, ...) which is updated to the latest server version. This web content is cached locally when pulled on-demand from the external web server and is version controlled, hence the "data-appversion", which is currently 4.9.3.21, which aligns with server version 4.9.3.0. When the "data-appversion" is bumped it invalidates your local cached files and the new version files are download on-demand. Sometimes this version bump may require restarting ET as it may be still using an old local cached version of the files. In comparison, the Windows App Store version bundles all the assets into a deployment package which has no web content dependency and is written exclusively in C#. Updates to this app are controlled through the Windows App Store. Kudos to @Lukeand his dev team for keeping this legacy version active. This version works best for me because it does not restrict usage and updates to the mpv-1.dll. The Windows App Store version locks down the mpv-1.dll from updates and disables loading external mpv.conf, scripts and plug-ins.

If you have the patience for one more check, look into your settings for transcoding. Mine were unchecked after I installed and maybe give it another reboot after replacing the text and checking the settings.

Yes that helps but both ways are feeling like a work around. Setting the chinese name is the easy work around, adding the series to the data base would work as well (havent done that but should in theory). I still think it is partially a minor emby bug since if the id itself is provided (and in case of the chinese folder name thats the only id that is set, correctly and automatically), it should just load it from the site and not try to autoset it to something else. If it has the english folder name and I set the same values, the meta data does not update correctly compared to the same id with a chinese folder name. There is also another weird interaction with the identify option that does find the correct series but sets it to something else.

Ici par exemple, le film de gauche ne passe pas bien, et le film de droite nickel. La seule chose que je vois de différent, c'est au niveau de "Coordonnées de chromaticité..", un est P3 et l'autre BT.2020 Est- ce que ça pourrait venir de là ? Sinon je suis preneur pour une explication

Ah, missed that. Still seems local device cache issues. Full on format / reset devices. Never experience anything on the SERVER side that affects local devices, but hard to tell. Again, the answer is no, not happening to everyone. Also, can't be just random permissions issues on the linux side?? Possibly, but why now all of sudden?

OP already stated they are using attached Android devices.

It isn't just you

Subtitles on DVDs (and BDs) are graphical overlays - so what you see is what you get. No font files are involved. Paul

No, not everyone, but most people that are "in the know" don't use TV Apps. We have dedicated Android boxes with decent hardware. Televisions are notorioulsy terrible when it comes to their hardware and eventual support. You could last ditch effort and "reset / format" your TV if you insist on using it. Seems like a local cache issue on the TV itself from my feable brain.

Are you using your own server or attempting to get access through someone else's? - in which case, check with them. If you have a server, is the problem with live or recorded? If live, then do you have a Premiere subscription installed in your server to enable live TV? If recorded, then more information, like logs etc is required (see Luke's post above for guidance). Paul