All Activity

is there anyway to "jailbreak/modifiy" apple carplay app to force displaing videos? not only audio formats?

Can you please reproduce the issue and then follow the instructions to send a log from the app? Also include the server log from the same time. Thanks

Yeah, but interestingly, on the same disc/file is another DTS-HD MA track (Surround 5.1), and that works just fine. Duration: N/A, start: 0.000000, bitrate: N/A Stream #0:0: Audio: dts (dca) (DTS-HD MA), 48000 Hz, 5.1(side), s32p (24 bit) Same bit depth...

Android first, if it works well then the plan is iOS too. Shouldn't be that hard to port the front end app

But Android-only, right? Hmmm...

This is completely unfair. If you start a business that creates a product it is "greedy" to not give it away for free? How do you pay the people that worked so hard on that product? Or the ones currently working on your next one? I'm sorry, but this kind of attitude is prevalent these days and just doesn't make any sense.

So, my guess would be that its the bit depth that is not supported by the device.

Hi. We do not pull directly from IMDb because it is a (very expensive) paid service.

Re-ripped the disc, and once more re-did the file. No change. Having a quick look shows that, according to FFmpeg, this file is Duration: N/A, start: 0.000000, bitrate: N/A Stream #0:0: Audio: dts (dca) (DTS-HD MA), 48000 Hz, stereo, s32p (24 bit) Whereas the other is: Duration: N/A, start: 0.000000, bitrate: N/A Stream #0:0: Audio: dts (dca) (DTS-HD MA), 48000 Hz, stereo, s16p

I'm not sure how you would know that nor if I agree as most people use systems straight out of the box. But, in any case, I would be fairly confident that most people do not have a situation exactly like yours where they would want to create collections directly from existing folders. But, I guess we'll see by the support of this FR. Thanks.

Sure, so you have somewhere to disclose concerns, and then that can be tracked there, but my point wasn't "what" is done, more "what is communicated" For all we know, the whole Emby team may have had sleepless nights and worked round the clock to push a fix, let the community know and they'll rally around you and be supportive, but taking a long time to reply and just stating "We're looking into it" doesn't illustrate what's is actually happening. The fact there was a CVE and there are other CVEs and there will be further CVEs is inevitable. But how this is communicated, how it looks to the users, the "optics" of the situation can be controlled by yourselves. Personally I was frustrated I bought up a CVE, created a thread, PM'd the team, my PM was read, yet I then saw multiple replies to other, somewhat, trivial threads occurring in the same subforum without any acknowledgement of either the thread or the PM, from memory it took about 1 hour to see my PM had been read, but then about 15 hours to get a reply on the thread, and my PM was never replied to. Granted I wasn't aware of the Github repo to report CVEs but at the same time, this was already being reported across the internet, so I don't think it would be classed as irresponsible disclosure. Improve the communication and a lot of the comments on this thread melt away. "Hi, thanks for bringing this to our attention, rest assured we're looking at it immediately, and our initial assessment is that we think there's minimal risk here for you guys, but if you wanted to be cautious, we'd suggest stop media ingestion until we push a fix, we intend to initially push a fix onto beta, and if all is well, after 24 hours, we'll backport it to stable, our provisional ETA to provide a fix and push to beta is 48 hours" See how the work you guys do is going to be the same, but the statement above gives a whole different perception to the scenario. Like I said before, I love the Emby project, but sometimes it's difficult to defend the communication, I'm genuinely not attacking you, it's user feedback and showing you how it looks from our perspective. None of this is a criticism of what has been done, other than I don't understand the rationale of pushing a fix to beta rather than stable, but again, communicate why that decision has been made, show us the rationale and maybe we'd understand. It must be disheartening to read posts like my last couple, but it genuinely doesn't need to be that way.

Log is attached. embyserver.zip

Thanks for beta patch.

Hola, aqui lo tienes. Saludos err_event.evtx

Wait I need to get pop corn for this

IS there really no way to have a compilation/soundtrack with varying artist names(not Various Artists) show as 1 album?

And now the fun part begins.

The issue is completely resolved. Thanks a lot for your professional support.

Less bad than the blog but same issue, it's very randomly updated

I've found another track which seems to be comparable (DTS-HD MA, stereo), and it plays fine. I'll go back to the disc and re-rip it. But before that, I'll look deeper into what differences there are between these two tracks, as one of them works.

Try here Announcements - Emby Community

Quick correction to my opening post: AudioMuse-AI has supported Emby since October 2025 and I should have known that before claiming there was no solution. Apologies for the inaccurate claim.

Maybe its linked to this same issue below? The fix on page 4 is trying Beta 4.10 but in the below thread we are waiting for a stable release of 4.10. I am staying on 4.8 on my Gemini Lake Synology NAS until this is fixed:

Unfortunately, re-doing the file didn't change anything.

That one ? https://emby.media/blog.html Last update on it is 3 years old