All Activity

Try going to TVDB and simply looking up "Danganronpa" (without the 3), and you will see all the various series for the whole franchise. Yes, it's a mess (and looking at the details in the Wikipedia article about it confirms this), but at least you can then decide which versions of what they offer you want to go with, and then name your files appropriately so they get recognised (appropriately, in this case, may mean including the TVDBid in the main folder name). Paul

Hi. No these things can not be customized at this time.

I agree! There is a conflation of Dolby and Broadcasters.

But that's not Dolby's fault. They are not "greedy" for running a business.

Hello. I know this thread has not been updated. I am curious if there are any updates to this option,;to physically move Cast & Crew underneath the, "More Like This" option.

Hi, Yes, there is a way - as per Emby instructions here: https://emby.media/support/articles/Music-Naming.html If you don't want to use "Various Artists" perhaps use "Soundtrack" or "Compilation" or any name you wish. You can also assign multiple Album Artist entities to an individual Album if you want to. Emby is very flexible in this regard. I have hundreds of Albums set up in Emby with many different combinations (e.g.) Album below is assigned as both a "Tom Petty (Tribute)" album and as a "Soundtrack" album, even though the individual songs are by "Various Artists". If you are not familar with Mp3tag, the OP screenshot may not necessarily be showing all tags assigned to a specific track. You need to "View>Extended Tags" to see them all. Sometimes there could be conflicts between (e.g.) "Album Artist" and "AlbumArtist" that might not be visible in the default LHS tag panel. Also, it's usually a good idea to update your embedded metadata with a tagging app and then import the changes into Emby. If you change the info within Emby only, then any library rescan is likely to revert to the embedded metadata. Perhaps try a few tagging options for yourself and see if you can set up something that suits your needs? Cheers!

Though I understand what you are saying, the reality is bit different. If you make a great product, you can charge whatever the market will bear. I'm all about that! Broadcasters are using PUBLIC airwaves, we the people grant them the licenses with the deal that they must broadcast OTA for free for those who can tune in. Locking up signaling behind a new encryption scheme (DRM) and new audio scrambling and requiring TV/Box/HDHomerun to license is anathema to bargain with the people. If they want to do that with 3rd party cable providers and/or satellite, fine, I'm ok with that, but not OTA. I encourage everyone to read Nicks thoughts on the matter. They are insightful and correct IMO. Here are some documents for you to consume. https://www.fcc.gov/ecfs/document/105252378905750/1 https://www.fcc.gov/ecfs/document/105250617122080/1 https://www.fcc.gov/ecfs/document/10605451007887/1 For those interested, can follow Nick's thoughts on: https://forum.silicondust.com/forum/viewforum.php?f=133 I wish there was more coalesced thread, but it's ok, I can follow along.

Thank u.

Hi. No worries. Just not a subject for this forum.

fair enough. i understand. i didn't ment to get anyone angry or something, honestly i thought where i can get info if not at the source. but please don't be offended. subject closed

Hi. If there is, this is not the place to discuss it. Thanks.

This is the first time I've seen the wording to be "Emby Home". When I use that, everything seems to work properly. Simple solution! Thanks for responding.

Granted - communication can be improved, but at that point there wasn't really more to say than "we're looking into it", because it required us to get several people together who are working on the build and release processes for the various platforms and all their expertise, views and concerns had to be heared and considered to get to a decision what we will do about it. Normally, we have two active build setups, one for beta and one for stable. For most platforms, FFmpeg is independent from the server build, but for most Linux based platforms it's not. Right now we're in a transition phase: The beta is about to become released as stable and we already have the other build path set up for the future 8.0-based ffmpeg. Trying to return to the old stable setup for producing a release with only the ffmpeg change could be risky and might cause regressions - but it's one option. The other option is to release the current beta as stable - as planned. This still takes a few more days to evaluate. So it's not that the beta gets the patch first because it has a higher priority. The highest priority is always the stable release as it affects a high multiple of users, and that means it requires more planning, consideration and testing than the beta and in turn may take longer to get a patch released. I can assure you that we are trying to get a new stable out as soon as possible - one or the other way. Thanks for your friendly criticism.

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