Leaderboard

Maybe a bug, but not a general stability issue => Feature Request => Feature Request => Not an Emby Server stability issue => Feature Request So, you begin by telling that Emby would have substantial and fundamental stability problems which are so severe that we should immediately stop working on new things and improve quality. Then you name a small bug (surely needs to be investigated but it's more 6 minutes than 6 months), followed by a list of your feature requests we should implement. Now, that's a bit funny... How should we work on your features when we must stop working on new features and focus on quality instead? Or should we just stop working on other things and work on your features instead? But wouldn't that mean that a general stability problem doesn't really exist? In that case, maybe, we could just continue our work, provide support for your issue and move this message out of the feature requests forum and follow up. Eventually, you'll be able to create (single and separate) posts for your feature requests just easy and normal...

Assuming you're using the same account on your TV as you used to purchase the app and that you purchased the app through the Google store (the Amazon and Google stores aren't linked) then try emailing billing support and ebr can contact you when he's back on. Emby Premiere Purchase/Subscription Support - Emby Community

That is not a false positive as its not reporting a problem with Emby but with the client IP. It's likely an IP that is doing port scanning and trying logins using common passwords or other exploits to gain access. Malware bytes reports back to the central server when it sees potential abuse on a system. When multiple systems report this same IP it's flagged and action is taken as shown above. This is one of the better ways of stopping this sort of thing as you know it's not just your system but also other systems the IP is "attacking". It's dynamic and constantly updated. If the IP shows no issues for 24 hours, it's removed from the "dirty list". As more and more systems use advanced detection systems of this type it makes the use of public VPN servers even less useful because they are notorious for use by people trying to exploit other systems. That makes the chancwe of the VPN public IP being on a "dirt list" quite high.

I'd really like to have 2 Factor Authentication added to the login screen. It's just this (optional) extra layer of security to help secure the server (which, especially if people use camera uploads) contains pretty private data. There are for every type of programming language quite a few libraries available, so implementation on a server shouldn't be too hard to realise

In the end this just creates a slow INITIAL import for Emby but day to day operates are unaffected as the processes are as fast as you add the media. But to do all of these processes and expecting normal operations is quite a reach in my opinion and users will blame Emby instead of their parallel import choices.

I will guess this has nothing to do with Collections page and to do with linked topic by Grim as Collections page has Sort-by and alpha-picker. You want the "Add to Collection" form redesigned? Making this a duplicate.

@Luke - I will give it a try and see what happens but as I am using the current version and nothing has been changed - I am not sure how resolved - but i will confirm

Not specifically for multiple extract processes I'm afraid. The ffmpeg command to do the extraction is actually listed in the 'quick-image-series' logs - but these days it's dynamic based on content - HDR for example now does tonemapping - so the best (and probably quickest) way forward is to just spin up multiple copies of emby, point to different libraries and let it run. For a script, If you start adding any sort of intelligence, it will get complex quickly but a 'dumb' script should be fairly easy - just iterate though the folders (libraries) with each one using a separate ffmpeg process. @Cheesegeezer and I added the BIF creator for HDR sources in the mediainfo plugin before it was added to the core - so technically this could probably be easily adapted to create an SDR BIF as required (if it does not already exist) - and then spool multiple ffmpeg processes based on a user selectable number in a config file or in the GUI. Could be library based or ItemId based - so it would have that advantage.

LG TV's do not support DTS.

Hello, sorry for the delay, but it worked !!! Thank you very much !!! regards

Yes a fix was made. Thanks.

No, from a random hacker poking your machine hoping to get in to something. Paul

Hi I know that there are alot of suggestions ... but the main request is: Please we need it as Netflix (same idea) if you make it only by create multi users and switch between them will not solve the issue. because the admin will always go to create these users and modify them . Please we want the user by itself to create these profiles and add restriction on it. for example if I create a user (account) for my brother, why i need from him to call me again to create another two users for his kids?!!! Appreciate your support

justed tested the plugin for the first time... Is the library scan really necessary every time ? Or are the tags not stored in the database but solely in the .nfo ? A possibility to have a user select and share his own top picks would be really nifty. And preferrably also have Top Pics Movies and a seperate Top Picks TV.

Depends on the version the new one has its own task (1.0.0.4) but the 4.6.0.22 (1.0.0.0) runs with library scan.

Well, in Browser Emby shows the Special Episodes.

Thats done the job! I missed that, cheers!

wow! this is exactly what i need! how do i install it? in the plugin section i cant found it. EDIT: is it done with copy it to the plugin folder and a restart? will this feature implemented in the emby server in the future?

I have been away from this thread for quite sometime and am slowly going through all the discussion. My thoughts so far, on the point of browser support : https://bitmovin.com/google-adds-hevc-support-chrome/ (Enabled and supported in builds of Chrome 104/105) @softworkz i totally understand your point that a lot of requests for this come out of a mis understanding of transocding settings, however the biggest use case I see is being able to make the most of limited upload bandwidth (residential connections on VDSL and equivalents) / bandwidth costs. I looking forward to getting involved in the focus group for improving H264 transcoding in the meantime.

As multi-version movies have to be named exactly as folder name, I'd guess that providerid is messing with it. You can use Auto-grouping plugin instead which should make short work of it.

filename.language.forced.ext, i.e. Ancient Apocalypse - 1x01 - Once There Was a Flood.eng.forced.srt https://support.emby.media/support/solutions/articles/44001159160-subtitles

I have done this for a new build - spin up 4 emby instances as vms on the same machine, point each one to a different library on shared storage. Opt to keep the metadata/bifs on the shared media. Kick off all 4 image generation processes. Once complete - then just add all the libraries to one instance. Or just write a bif script if you just want the thumbnails...

I'll admit it's a personal rather than a technical thing. Ubuntu reminds me of Windows a little bit. I feel they try to make too many decisions for me like putting in cloud-init without asking on server installs. I can't deny that does contribute to stability though. It's also not a rolling release which I very much prefer. There's also personal history. It was the first Linux I was able to stick with. Before that I'd try Linux every few years but, until they.had package managers, I'd wind up in dependency hell. I might still be using it but, they came out with that horrible, dead for good reason, Unity interface. That goes back farther than a lot of people on here but, I have a long memory. There's a reason I use Arch on my daily driver. However, the AUR is too unstable when my wife's going to chew me out when her TV's not working. So, I'm looking for something else. Suse looks good. BSD has possibilities and might be interesting. Too much of a learning curve for now though.

That is what I was thinking unless you config A library per server they will all potentially do the exact same thing.

Very good! For scanning please see my reply to your other post: https://emby.media/community/index.php?/topic/113885-chapter-images-not-displayed-in-tv-series/&do=findComment&comment=1201660 For extraction: This is a single-thread operation. Decoding a key-frame is not a task that benefits from multiple core. Neither does it benefit from GPU decoding. I think I have explained that already. Faster IO is the only thing you could to to accelerate thumbnail extraction. @Luke will need to respond to that. Yes, this has always been planned for and the architecture is there. You also see that you can already select multiple GPUs for each codec in a priority order. The only bit that is missing is some logic to determine under which conditions, the other GPU should be chosen. We're not far away from making that possible - technically. I can assure you this it wouldn't accelerate this. Not even a tiny bit. It would accelerate the old way of extraction. But the old way with GPU is still much slower than the new way (where CPU vs. GPU doesn't differ).

I'd recommend grabbing the DS920+ and setting up SHR (improved RAID 5) on Btrfs. You don't need to fill it up with drives, you can buy a couple of fairly big drives (as big as economically possible), and put more in whenever you save money and/or start filling them up. Additionally, the DS920+ has a couple of m.2 NVMe SSD ports that do wonders with R/W caching (great for Emby snappiness) that you can also add in the future (dirty cheap NVMe drives will do a great job, no need to spend money on faster ones, as the difference will be negligible). The major thing as for what drives to put in, each person has their own brand recommendation (mine is WD, which are a bit more expensive than Seagate, but are more reliable), but one thing is universal to all brands: don't get an SMR drive, always go for CMR, even if the price is higher. Performance of SMR drives on NAS environments is awful.

Yeah, should be able to work around the text in brackets. Ill take a look tonight and see what is possible. For the beta (auto organize plus) you have remove the fileorganizer.db to get it working right. It's kind of a pain I know.

@chef

Yup! 100% agree. I've added for the next release.

Don't underestimate the interest in getting HWA if/when Emby introduces that feature-set. Right now it's just not needed to think about getting a card into the server, but as soon as emby can do AV1, to, for example, generate higher quality low-bandwith-streams, or can target HDR-live-transcoding, including fancy stuff like DV5 to HDR10, this might change. All that being said, there are good reasons here for why it's not rushed into the code to just have an interesting name-drop in the changelog.

Dedicated GPUs will become interesting again once emby allows transcoding to AV1 and/or maybe if we can do fancy stuff like DV to HDR10 live-transcoding in the future, but the current stuff is easily covered by a half-modern intel CPU with iGPU. QSV has become really great.

This will be in Emby Server 4.8. New playlists going forward will be private to the user who created it, and there will be a new context menu option to share the playlist with other users.

Hi, the icons I'll get to fixing but this change about the letters isn't happening. In RTL the whole interface flips direction.

Thank you! That did the trick nicely.

Use Server Configuration Backup Plugin and sync playstates and rest. https://support.emby.media/support/solutions/articles/44001159936-configuration-backup

@cayars, thanks for that post. I wasn't up-to-speed on some of these developments. Do you know if the fMP4 specification is encumbered in any way? HEVC was in trouble early on, as patent pools and groups were already busy cross-licensing with each entity. You don't have all these members of a working group going through the expense of getting hundreds of patents just to give away free (or even simple) licensure. I have my doubts that AV1 will be problem-free in this regards as well. The "fair licensing" scheme is basically a gentlemen's agreement; the pool of patents is in the thousands for this...if revenues don't meet expectations, this could easily factionalize. This is disappointing, as AV1 is allegedly a successor to VP8 and VP9. This is just another example of why we shouldn't tolerate patents on mathematical equations!

It can sure. In general, it can also add a lot more latency when done in real-time vs pre-production. It can/will change the packaging needed by the clients and will need more stringent encodings to meet spec as well as most of the time require fMP4 chunked packets (fragmented MP4) which typically causes a loss of compression vs offline encoding and using progressive downloads. This type of thing is covered throughout the thread. The simple answer is that we can't just substitute an encode string creating HEVC vs AVC encodes. Up until about 1.5 or 2 years ago there wasn't even a spec for using streaming HEVC so its use was mostly progressive downloads or to specific devices you knew you could get away with using off spec packaging in HLS. Apple however added to the official spec for HLS recently introducing fMP4 as well as TS segments. AVC can be used either way, but TS do not support HEVC and had to be handled via fragmented mp4 packets. Manufactures who were "loose" allowing incorrect packages have had to fix this to support Apples changes to the spec causing tumoil to vendors who were using packages out of spec and banking the chanes would favor them (nope). Everyone quotes high compression savings of 40% but that's extreme and only with higher bit files. The difference between AVC and HEVC closes dramitically as bitrate and resolution drop. HEVC separates itself from AVC at higher resolution, but the opposite is also true that AVC compression is closer to HEVC the lower the resolution. A 15% or so compression difference on 720 files surely isn't as compelling as 40% compression savings of 4K (if all else equals). Up until last week the top browsers didn't support HEVC, the ones that worked were finicky, we had no standards in place specifying what was allowed and what wasn't. Mozilla/Firefox will likely never support HEVC while Apple, Google and Microsoft now all support it. Many used DASH instead of HLS to deliver HEVC since it's more a "Swiss Watch" container allowing more or less anything. Problem is support for DASH is missing from the majors. HLS vs DASH is not unlike the old media was that DVD and Blu-Ray went through with competitors to win out and take the market. The reality of the situation is that up until very recently this would likely have been a big mess undertaking it for our style of media streaming server that works in real-time. Here's a short article that might be worth reading as it covers some of the reasons HEVC will likely be a transitional codec more so than a mainstream use codec for streaming servers doing transcoding. It's not technical so all should be able to understand. https://www.studiobinder.com/blog/hevc-codec-download/ That doesn't mean, we've done nothing with this request. We can do HEVC transcoding and know how to package it properly but the changes needed to support fMP4 comes with it's own set of issues like additional latency which negate the benefit of compression gains. We know from testing it requires a more powerful CPU then AVC even when used with a GPU. We know HEVC can give increased compression due to how it's encoded but that encoding takes longer to do as well even on GPUs which raises latency and that's a killer for streaming. We already know from doing AVC transcoding that's we've had to reduce packet sizes to keep latency at a level that doesn't cause issues. We really can't afford to add this latency back as we've worked hard to reduce it. HEVC has all kinds of licensing issues. It's certainly not "free to use" as everyone seems to think. With so many hurdles using HEVC for real-time transcoding it's probably best to skip it looking at the next gen codecs being introduced to replace it that take into account HEVC's shortcomings. The industry learned a lot of hard lessons with HEVC that have been addressed with the newer codec. Reading the requirements for next gen codecs reads like a list of pros and cons from HEVC as you want to do this plus 30% improvement but can't do this. There are things we can do related to this request that could improve transcoding across the board. There are a good half dozen promising things I'm personally looking at that could improve latency as well as reduce bitrates currently being used on typical media. We can also look at implementing HEVC as a starting point for specific types of streams such as 4K where it could shine. Clients that can handle 4K HDR could be targets starting out as they should have the muscle needed to handle this without causing additional issues. It would be a starting point, then 1080p on same clients and so on. If some of the other things pan out and have the ability to lessen current latency, we gain a window of time back making it easier to introduce things like HEVC that we know will increase it.

If you want to understand, I'd kindly ask you to go a bit back in this conversation and read.

Hi, I apologize for the mixup. His opinions on this feature are his own based on his experience and don't impact whether we'll end up doing this or his. Like everything else, it primarily comes down to what people want. There's enough users in here that I think it's inevitable that we'll end up doing this.

first, I don't think anyway is suggesting disabling h.264 support so web browser access shouldn't be affected. second, zero percent of my users are using a browser. It's all apps or TVs. All devices that fully support h.265 and some that do AV1 as well. I think this is the most typically use case. Right now, emby streams are far inferior to the likes of Netflix and Youtube etc. We are basically a decade behind in streaming tech and the mobile/remote user experience suffers as a result. This makes Emby essentially an in-home platform for my family because it really drags streaming it out. I have symetrical 1G fiber btw. Mobile networks are my issue and having double the bandwidth requirements for mobile is the strain.

Yes it's something we can look at. Thanks.