dabl

After becoming disabled again very shortly this time after getting it restarted I gave up on the Dynamix plugin for now and returned to using unraid-fan-speed.sh with the user scripts plugin to start at boot. I forgot the 'cron' part was built into the script. I disabled the Dynamix fan auto control plugin but the speed of the fans shows up on the dashboard 'Airflow' section which is good.

Same thing again, guess I'm an idiot to keep trying this vs returning to good old fanspeed.sh and cron....... raid-01-diagnostics-20190724-2155.zip

Since the above post from 6/26/2019 and re-enabling per above the plugin maintained a Status of 'Running' for 12 days then stopped again for whatever reason. Re-enabling this time per above took many attempts to get a Status of 'Running'. Hopefully the attached diagnostics will be of some use. raid-01-diagnostics-20190709-1749.zip

Another user after updating to Unraid 6.7.0 seeing the Dynamix Auto Fan Control plugin behavior broken but in my case not all the way. From a Status: Stopped state I can reset using the Default button and enable, detect and apply and it will run for some period of time, still not sure what length of time that is exactly but it seems to be longer than 12 hrs but shorter than 24 hrs. Diagnostics attached. raid-01-diagnostics-20190626-1220.zip

Here's the original request at the top of the page with a link to the details.

Yep, I too am still very interested in DSD support

I read (and thought) the same. I had been targeting the Linuxserver.io headless Kodi docker but since some there seemed to now favor this one I came here. Unless I'm missing something, it seems using the Emby docker strictly as a back end for Kodi clients doesn't cover the same use cases though. I need Blu-Ray .iso support on Nvidia Shield TV Android clients which works well with a traditional Kodi standalone back end and (presumably) a Kodi MySQL shared back end. The Emby server doesn't seem to currently support .iso for Android clients and .iso support in general with an Emby server seems very limited. Further, movie folder support in Emby in general seems to be limited and many if not all recent replies from Emby support for .iso or movie folder playback issues suggest converting to .mkv I'm becoming convinced converting everything to mkv will make life easier in the long run but for me that's a lot of converting to do. I don't mean to belabor this in a docker thread but just trying to learn and perhaps alert anyone else coming here running Kodi on Android thinking swapping to an Emby server as a back end is some kind of simple no brainer replacement for a traditional Kodi standalone or Kodi MySQL solution.

All my movies are in separate folders.

Huh. So the Emby devs acknowledge a major bug present in 4.0.2.0 and earlier causing multiple people to lose data, issue a 'hot fix' then don't update the docker until they feel like it? Obviously I meanwhile turned off delete for all Emby users in my docker but..... I have yet to post my story over there. I have all the logs etc. I deleted a single .mkv using the Emby 'Delete Media' function using a freshly installed Emby 4.0.2.0 docker and lost 100 movies in seconds. Most of the stories/replies in the Emby forums about the issue seem to imply that the problem is limited only to DVD images and/or previous installs upgraded to later versions. Not so at least in my limited experience.

So speaking of updating, I started reading from the first post for a few pages and know there has been some if not much previous discussion on this. I see 'Version 4.0.3.0 is now available' on the dashboard but when I use the Unraid Docker Containers page 'Check for Updates' I don't see an update available. When I run 'force update' it runs (emby/embyserver:latest) and finishes successfully but the Emby dashboard still tells me I'm running 4.0.2.0 and that 4.0.3.0 is available. What am I missing?

I'm a new Emby user but an experienced Unraid user. I had a similar 'delete' incident as described but was far more lucky than David Bott. I only lost 100 movies before realizing what was happening and (as calmly as I could) stopped the docker before more damage could be done. It all happened in about 10 seconds I'd say. I stupidly used the 'Delete Media' option in the Emby docker on a single movie. I just happened to have a Windows Explorer open and watched a bunch of movie folders start disappearing. Evidently there is/was a bug there too and/or it's the same one (hopefully fixed). This happened to me a couple of days ago. I know I'll never use that particular mechanism ever again to delete a movie either way So this is all very timely discussion for me as well.

Thanks!

Cool, thanks.

Amen. Gotta say, not great the plugin author pushed an update with no release notes, no notice in the thread, and isn't around to weigh in on issues afterward. But this has happened before. Another reason to have/use the good old command line script with screen etc.

Thanks for the explanation, good to know. Right, not that hard, except not nearly as easy as pushing a button to fuck up what was working a minute ago To me the whole 'push a button to update your plugin' thing is somewhat deceptive and far less appealing and useful without a mechanism to roll back baked into it. I'm sure I'm not the Lone Ranger here starting to think about how I'll go about making my own backup strategy before updating plugins........

Thanks. Wow, so then, not particularly easy at all really. I'm curious if it the case that the unRAID plugin system itself has no built in mechanism for rolling back any given plugin to a previous revision or is that functionality left to the plugin developer?

What's the easiest way to roll back to version 05-03-2018?

gfjardim, I saw the 2018.07.09 update but there's nothing in the release notes after 2018.05.03 What are the changes in this most recent update please?

Ah ok. Yeah I've had that happen more than once and posted in this thread about it as well. In my case all were with Western Digital Red drives for what that's worth. If the alternate script solves this consistently that would be huge.

Did you experience a problem with the default gfjardim plugin script that you didn't experience with the binhex patched bjp script?

Ah ok, now we're getting somewhere. So the drill to recover from a broken container was to simply re-install using the the unRAID 'Apps' page. Select the green 'Hamburger' icon, then 'Previous Apps', see tvheadend, click to install. I did in fact see the 'bad' path I added before and simply used the 'Remove' button to get rid of it and hit 'Apply'. Everything back to normal. Thanks for your help saarg, greatly appreciated!

Ok, thanks. I may be a little confused on exactly what you mean when you say the volume mount I added and exactly where I should look for that. Just to be clear, I edited the docker and choose Add another Path, Port, Variable, Label or Device Then in the Add Configuration dialog window I added the below Config Type: Path Container Path: Script Host Path: /boot/custom/bin Looking at the file from the CA Backup / Restore Appdata plugin I see it's just a .tar and contains the entire tvheadend folder from /mnt/user/appdata I should be able to restore that easily enough (I think) but wonder how to handle the Docker template. Would it make sense to try and re-install the docker using Community Applications and then restore my tvheadend folder from the backup?

Thanks for the quick reply and info on how to do what I was trying the right way. I've never done any kind of restore using the CA Backup / Restore Appdata plugin. Looking at the manual it seems it's designed for a disaster and restoring everything. How might I attempt to remove what I added in the template?

Newbie with this docker needing some help please. I attempted to edit my working docker and add access to a share containing a script but it seems perhaps my idea to use this particular share was not a good one (/boot/custom/bin). After hitting apply and seeing a failed startup I see now the docker no longer appears in the unRAID Docker Containers page Basic View. Advanced view in the unRAID Docker page shows the below (orphan image) Image ID: f28ecf1b0581 linuxserver/tvheadend:release-4.2 Might there be a relatively simple way to recover, a file I could edit or perhaps a restore of some kind from a daily backup I took using the CA Backup / Restore Appdata plugin? Thanks for any help!

I too am interested in the answer to this and/or advantages/disadvantages to either.