Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 02/05/26 in all areas

  1. Ask and you shall receive: https://github.com/music-assistant/server/pull/3096
    3 points
  2. Now this guy loves his Emby!
    3 points
  3. It can. if the server sees the client as remote. Try this in your lan networks. Replace 192.168.50.229 with 192.168.50.0/24 Here is my network config. 1) 10.253.0.0/24 - VPN access. 2) 192.168.1.0/24 - local lan network. 3) 172.17.0.0/24 - Docker network.
    2 points
  4. @softworkzCan you please increase the ffmpeg version number to lets say 15, so people think they have always the latest and greatest?!
    2 points
  5. I mentioned it in another thread, but thought I'd put it here since this looks like a new section--just for posterity. Would like to have a bulk meta data editor function. For example, if I have 750 videos whose producing studio is the same, I want to select those videos and apply the name of the studio to those videos. Similarly, if there is a custom tag I want to apply to a subset of those movies, I want to be able to select them in bulk and apply the tag to those videos (instead of selecting them one by one).
    1 point
  6. Emby for LG 1.0.50 has been released. Here are the highlights: Resolve playback error on some 2018-2019 models Merge Movies and Shows into a new Movies & Shows tab in mixed content libraries
    1 point
  7. I was checking out Jellyfin and noticed they have a Custom Tabs plugin that can add new tabs to the Home/Favorites menu. So I added a "Requests" tab which launches Jellyseerr in an iframe and it was awesome. Unfortunately there's no such plugin for Emby that I could find. So I resorted to modifying web files and wrote a script I can run whenever the container needs to be re-built. Here's what it looks like un-selected: Selected: The only thing I have left to do is implement SSO so users don't have to login to Jellyseerr manually. Instructions in next post...
    1 point
  8. No VPN and there is no external access. Everything is on the local 192 subnet.
    1 point
  9. Just a quick suggestion. Adding a manual timestamp in Season Batch Validation to a single episode kicks you out after applying. It would be my preference to allow as many CRUD operations as I'd like, and when I'm actually finished I can click the "close" button.
    1 point
  10. sure the setting is on. this is weird I just checked another one like back to the future and that movie is in both collections. strange because I'd didn't do anything with the godfather movies. anyway it seems and I hope you're right thanks happy day
    1 point
  11. Hey. I don't believe that to be related to the plugin. I've not pushed any updates for a while now and there are no other reports like this. Also wouldn't make sense in terms of what the plugin does. The setting that is adding these movies automatically to collections is an Emby setting. It's a library settings. Do you have it enabled?
    1 point
  12. It is entirely too easy to accidentally mark a series or season as played. More than once, I or someone in my family have clicked that check mark and the damage is done. There should be a confirmation popup that confirms you want to mark a series or season as played. It should use that language to make sure the user knows that they are about to do.
    1 point
  13. Did you read an understand the help text under this ? Are you client devices on the same subnet as your server? How are your client device connected ( wifi / cable )? If wifi have you restarted your router? If wifi do you have AP Isolation enabled on you AP? If cable are you using a managed switch with multible vlans?
    1 point
  14. 1 point
  15. That or you could ask them to install the latest version via USB.
    1 point
  16. That is what I suggested in the issue raised with the development team. The episodes whilst having the same title, do have different season/episode numbers and different TMSID's (a Gracenote episode ID)
    1 point
  17. First of all, thanks for taking the time to post - some interesting info here - some way above my head as I'm a network/security guy, not a storage guy I think this goes back to the point you made on the availability and accuracy of the data and a point I stated in my explanation on why I do it this way. "For static media content.." For anything that you can reproduce bit-for-bit from another source - then the option to recover this yourself, at your cost (time/effort), is 100% your choice. If a video file (99% of my storage pool capacity) drops a bit or even hundreds of bits, generally, error correction in the codec will simply ignore/mask it and carry on. Yes of course there will be a time when corruption kills the file but that is rare and unlikely to be caused by I/O. On the flip side, I agree 100% on if you lose a bit of a dynamic data/bin file then you are in trouble. This is why I do run drivepool across 3 platters for the important files - but none of my emby system, video nor metadata use this pool for the above reasons. Again, key word here is static - I have a 'point in time' cold standby system that i can bring operational on the network in 5 minutes while it boots. At the time of the backup/sync (as that's what it is) it was 100% verified from the backup software. Can I guarantee it's 100% bit for bit - no, but as above, it doesn't really matter. It also puts to good use all my upgraded 'old' (but still serviceable) HDD's - so my backup/recovery system actually runs more than twice as many HDD's as my primary system - because the HDD's are at least half the capacity of the new 'live' ones. But as it's offline, it doesn't matter. For Enterprise class storage - I'm 100% with you, but for home Emby storage - my solution works well for me as I have traded recovery time/effort for less spinning platters and storage complexity on my live system.
    1 point
  18. I doubt this will be of help, but just a thought. There was an update a while back (don't remember which one or exactly when, sorry), but it seems that that is when this started. There was a rash of these new fanart files, 5-20 at a time daily, then they tapered off. Since my last batch on Monday I've had nada. It's almost like a flag was set to 'ok, done that one' and hasn't repeated itself. I didn't keep track of which movies were affected, but I am sure that it only did it to a movie once. In the immortal words of Buffalo Springfield "For What It's Worth"
    1 point
  19. Unfortunately faced issue with 3.5.28 as well. I didn't have the logs on. Again this is intermittent. Let me see if I can reproduce the issue.
    1 point
  20. Cant wait to see implementation. Thanks for quick reply. @Luke
    1 point
  21. App settings -> Display -> Preferred TV show display -> Always show season folders.
    1 point
  22. https://github.com/DanielVNZ/Aether/tree/main Screenshots are up on github thanks!
    1 point
  23. This has now been Dockerized! Check it out if you wish at tophicles/dash:prod-latest
    1 point
  24. Hi Luke, thanks a lot. I will try it. Greetings Michael
    1 point
  25. Hi, not currently, but we plan to support a channel number function in future updates. Thanks.
    1 point
  26. It is compatible with YouTube trailers now, yes.
    1 point
  27. Eagerly awaiting this. Trying to save money so I don't wanna spend the cash for WinTV if this is coming soon, and I'm not ready to upgrade to an ATSC 3.0 HDHomerun considering the DRM debacle. I'll hop on the beta test right away - this is just about the only thing keeping Plex on my PC!
    1 point
  28. @LukeIt makes sense not to overload the activity log unnecessarily
    1 point
  29. This makes sense however that doesn't mean it can just be made on a whim. We have to look at what the impact would be to existing users. So for this reason, sometimes this sort of change might have to wait until we can bundle it with other larger changes.
    1 point
  30. I strongly believe in using arrays, and I agree that having to rebuild a drive in an array is quite an intense operation if you get unlucky and have another drive failure where the array wasn't designed to handle that scenario, you're effectively re-reading all of the data and recalculating parity and writing out to a single drive (which is the bottleneck in terms of speed) but I run monthly scrubs which is doing almost the same thing. Whether you go 1 2 or 3 disks of parity is dependent on a few factors, for large multi-TB arrays it should be at least 2 drives of parity with checksums to deal with bitrot. My main issue with using single drives is checks and balances - how do you know that the data being written was written correctly? How do you know it was read correctly? Especially if you're not using ECC RAM in the system, bits can and absolutely do flip in memory randomly. If you're using something like DrivePool where you have the option to just slot a drive back in, sure you can do that, but I don't believe in keeping data on a single drive without any parity information or ways to detect corruption. Also that means you have hardware lying around unused that you may need to manually maintain in terms of making sure it has all the same information a few months later. Having a backup is absolutely important and is an extra cost. I put my extra cost into a second array instead, which is always available and has a similar maintenance strategy. At the end of the day the implementation you go with will depend on how much you care about the availability and accuracy of the data. I used MD raid for a while and had to deal with scenarios of needing to repair the data on the XFS file system and later on went with a ZFS solution for availability and data accuracy reasons - especially when it comes to very large arrays with a lot of data. The majority of people probably don't need to do this and probably don't even care. This video covers most of the topic much more eloquently than I could write out. There's also a really good followup video too.
    1 point
  31. We are coming up on 3 years since this request was proposed by the OP. That seems long enough to "think a little more broadly" and admit that no use-case will cover ALL Emby users, and may not even cover a majority of Emby users, but it will cover the ones that have the knowledge to enter SMTP server information into some fields, which I would argue would be a significant portion of the userbase. Most of us host our servers in homelabs, so know how to tinker with the technical. I'm not sure why we're stuck on paralysis by analysis for this one particular issue, which is fundamental to many of us for a service we host and share with family/friends. If someone wants it bad enough, they will figure out the technical aspects to get an SMTP connection working, which is a trivial task with many modern mail hosting services.
    1 point
  32. 1 point
  33. imo RAID5 or any form of a parity disk is very out of date now, especially with multi-TB disks. The rebuild process is a huge red alert where your entire array is at serious risk and also putting significant load on it while rebuilding, leading to possibly causing more failures = end of array. For static media content, I've gone done the route of no redundancy at all - but I have a 1:1 backup on offline HDD (or across multiple HDD's). Should a disk fail, I simply swap in the backup disk (into the pool - it's flexible enough to do that) and I'm up and running. The replacement disk becomes the new backup once I've copied it. No rebuilding, no parity, no extra risk. I tend to use previously upgraded HDD's (capacity/density) as the backup HDD's. The bonus of course is you also have an offline backup, which is NOT the same as RAID. For constantly changing storage - then yes, some for of duplication is essential - but for static media, my argument is why do you need to be able to reproduce it on the fly ?
    1 point
  34. We are working on it, but we don't know yet. We have a line of contact with the Vega developers and we may actually have to get some things added to the OS. So we have to go through this back and forth process with them, complete development, then submit it to them for review.
    1 point
  35. This is the Nth time this issue is brought up here but has yet to be fixed by the Emby Team - it affects more than just Android, the Shuffle "randomization" is fundamentally flawed and makes it unusable, especially for large music libraries as it seems to "randomly" pick between Titles starting with 1 and Titles starting with A - its infuriating. How come this is still a thing @Luke? What is the reasoning behind "pseudo-random" Shuffle that only picks a minuscule subset of options? Please finally have a look into this, it affects all platforms and all players and all media types! further example posts of this BUG fix proposed a year ago by @visproduction "We are looking into this" has been commented by Luke for at least 2 years - so far ZILCH
    1 point
  36. Any estimated time about this feature ?
    1 point
  37. The limit was created as a means to slow down the illegal use of our platform because that puts us at risk.
    1 point
  38. This idea is pointless. Establishing an entire VPN tunnel using Emby players as a client and the server as the server is far more complicated than just using proper TLS with certificates. You gain literally no advantage by using a protocol like WG or IPSEC instead of TLS in this manner. Just implement proper 2FA using TOTP. It should take less than a day to implement this using widely available libraries and most users already use TOTP for other things. Passkeys would also be extremely easy to implement and use but have slightly lower adoption and user acceptance so far.
    0 points
×
×
  • Create New...