All Activity

It is more for @ebrand I to see if perhaps the server is adjusting our things after the fact. I think we are sending them correctly and the server is change them or something. The order of the AudioCodecs matters. The very first codec listed is what the transcoding will be used. In this case it has AC3 there which is most defintely wrong. Have you disabled any transcoding for that user. Specifically have you disabled audio transcoding for that user?

Hi, there is no limit. This is just an issue that we are looking at. Thanks.

I'm mildly following what this means.

AudioCodec=ac3,aac,mp2,mp3,eac3,flac,vorbis,lpcm TranscodeReasons=VideoCodecNotSupported,DirectPlayError&allowVideoStreamCopy=false&allowAudioStreamCopy=false For some reason AC3 is in the front before AAC. In checking the capabilities code in the Roku app we always placed the AAC codec first in the transcoding profile. So that the server understands to convert to that when it must transcoding audio. But look at this here the server is showing us. AC3 is placed first. I do not think you can convert EAC3 to AC3 or rather it isn't converted but stripped of the extra channels. Because it is trying to pass the stream in untouched from the audio. My guess is your Roku only supports Stereo due to how you have set up the audio settings on the Roku. I've confirmed this happens and got the same error on my Roku. I disabled audio transcoding for that user. Now when I only support stereo via Roku audio settings and attempt to play that item with EAC3 back I get the "No compatible streams" error with a red box. @ebrDo you see anything where AC3 would be placed at the front of the transcoding profile? Maybe my eyes missed something. This is defintely the issue is the audio transcoding EAC3 to AC3 instead of AAC. Its weird because if you notice in the Roku code AC3 and EAC3 are always be placed together. One after the other. But here in the AudioCodec line from the server its changed position. How is the happening?

Hi We have made a change in Emby Server 4.10.0.21 beta to send the WOL magic packet to udp port 9 of the broadcast address for the network - so for 192.168.1.xxx subnet the magic packet containing the target mac address is sent to 192.168.1.255 I have not been able to confirm it is working - for some reason my Dell laptops are refusing to come off sleep after I force sleep through the power button options of shutdown / sleep / restart. I have tried also with windows wake on lan app and ios wolow app - my laptops refuse to wake up with the magic packet ! Could you confirm if Emby Server beta 4.10.0.21 fixes the issue you reported ? You would need first to use the emby client app with 4.10.0.21 so that it gets the WOL details from the server running 4.10.0.21 and then test out the wake on lan from within the Select Server ... menu Thanks

@LawragetvOS playback pipeline has a HUGE update coming today.

Yeah, once I confirmed it fixed the issue I just disabled “save JSON with metadata” and ran another restore, and everything seems to be working now. Re-enabled it afterwards, so it should overwrite the bad JSON files with the correct data on the next backup.

got it. here you go. there's a few shows its doing this to. but I figured if a solution can be found for one it should work for all correct? embyserver.txt ffmpeg-transcode-1c3f7918-338a-4251-aa05-2ddb78e13c44_1.txt ffmpeg-transcode-72bbe66a-d0b7-4650-99ff-1d60a727fc83_1.txt ffmpeg-transcode-613e42d9-1b7a-4817-870e-7a9722e050ba_1.txt ffmpeg-transcode-8771eea2-5db2-4378-9f91-4b6c2b56488d_1.txt ffmpeg-transcode-c1aa1bb9-dffe-4708-9c2b-c23bf00b8909_1.txt

It's almost August. Back in March, the expectation was that this would be nearly finished, right @Luke Since I’ve been waiting a long time with no visible progress, I’m going to explore the Docker route I guess.

Thanks, but I'm honestly super-confused by this. I thought a DDNS service maps something like `emby.mydomain.com` to my IP address. However, when using Emby connect, there is no `emby.mydomain.com` because I'm using Emby connect instead.

That's not my point, but it strikes me as strange that Android/Web users can just use the app "normally", even if that include playback and that playback is actually blocked for iOS users. That actually baffles me. If I have an Emby installation and happen to have an iPhone, I wouldn't be able to use the app on my own local server?

Log Files

@SamES Information requested Model TVs are qe55q80 running 2740.1 Samsung The Frame from 2022 running same firmware. Usualy its between the end of eppisode 1 and the end of 2 with all of the files being around 45 mins. Yep understand your position. Today I have done a lot more testing and I think I have found the cause or pattern. Its this WS Matroska Muxer I had some files that were 720p for the same TV series so I ran that test this morning. No issues 5 eppisodes in. This is because I already watched season 1 and 2 and then i upgraded the rest to 1080p files but one thing all the crashed files have is they use WS Matroska Muxer. To confirm this I went and found some new files that used this to encode (Forgive me if my undestanding is off). Completely different show, different drive and yet same result. I will send you some files as you requested.

Thanks! Let me know if there are any solutions you'd like me to try via betas, etc.

How do I do that

Its just a generic playback error on the app end. The issue is related to the transcoding and the other apps may not be doing that. Please provide the server log and all the ffmpeg logs that correspond with that failed playback. Thanks.

Thanks for the reply, but won't all of us who are affected by this bug end up in the same situation when the "Legacy" scanning option eventually gets removed? Or are there no plans to remove it? This isn't a one-time breakage upon upgrade or schema migration. It will break all existing entries whenever the library is scanned, if "Default" scanning mode is set.

Thank you for the information, hopefully that that improvement is on the roadmap.

Hi, are you still having an issue with this?

Hi, have you tried it?

Because that results in hammering the metadata providers with huge numbers of requests and they have asked us not to do this. That is why it’s on demand. That and I promise you wouldn’t like the library scan time that would come with that.

Caddy is a lot simpler so you don't have to mess with most of that. Just use the example Caddy files that are posted out here.

Yes and I recommend using Caddy as it is dead-simple. Connect or not your domain is the same - whatever domain you have created/obtained. Think of Connect as nothing but a dynamic DNS service. It just maps a forum account to a local server one.

Hi, yes genres have always worked this way.

Hi, yes you can. Lots of users here use caddy. I would suggest comparing your reverse proxy config to this: The guide is written for nginx but most reverse proxies have similar options.