dragonfyre13
-
Posts
44 -
Joined
-
Last visited
Content Type
Profiles
Forums
Downloads
Store
Gallery
Bug Reports
Documentation
Landing
Posts posted by dragonfyre13
-
-
Is there any specific reason why this plugin is checking where the install directory is located? Usually on Unraid, appdata directory needs to be persistent so config files and databases are saved, but the install dir is supposed to be on the ram disk (not persistent), unless there is some aspect of nzbdrone i don't know about that gets dropped after a non persistent reboot?
Not really. Main reason is just that I had it in there for previous plugins (checking the install directory) and because it made sense when the appdata directory HAD to be underneath install. Suppose I could remove the check, but I'm not sure what issues that could/couldn't cause if the install directory isn't in place. I'm not sure if there's volitile data stored there, though would assume not given associated information and the form I'm unpacking it from.
-
That is the link I meant to post.
Sent from my iPhone using Tapatalk
Did my best, let me know if there's any more question about it. Might be better to discuss this one on this forum, since it's specifically to do with how unraid handles recognizing the root level mount point. My answer is here for reference (question was around an error in the logs regarding not being able to retrieve currently free space for the / partition):
The issue described is actually pretty simple when understanding how unraid works. / has no defined free space because unlike general purpose linux distros, it's not mounted per-say. It's running out of RAM by default (after bios loads GRUB, GRUB loads the linux image into RAM and since / is never mounted...), which also means anything stored there is blown away if the machine reboots. /boot is mounted to your flash drive (which it unpacks the OS from before loading it into RAM), /mnt has sub-directories under it for each of the disks, and a few "virtual" directories that combine all the contents of all the disks (/mnt/user and /mnt/user0, /mnt/user0 is whatever disks combined minus the cache drive IIRC). This is why the installation path and config path have to be set in the unraid plugin, since they need to be somewhere within either /boot (bad idea, lots of hits to your flash drive drastically reduces longevity) or /mnt/something. Personally, I have it on my cache drive, you can also choose to have it on a different drive if you don't have a cache drive. Of course, the option is always there to have the config on one of your drives, but the installation held in memory (stick it somewhere other than /mnt/something or /boot) since unraid re-installs any plugins needed on each boot up, which is why plugin logic needs to account for this.So for example, this is the drive configuration on one of my unraid boxes (I have two, it's an addiction, and before you say it I know I need to clean up my drives on this one a LOT):
# df -h Filesystem Size Used Avail Use% Mounted on /dev/sdd1 31G 532M 30G 2% /boot /dev/sdc1 120G 45G 75G 38% /mnt/cache /dev/md1 932G 853G 80G 92% /mnt/disk1 /dev/md2 932G 797G 136G 86% /mnt/disk2 /dev/md4 1.9T 1.7T 207G 89% /mnt/disk4 /dev/md5 932G 841G 91G 91% /mnt/disk5 /dev/md3 1.9T 1.7T 137G 93% /mnt/disk3 shfs 6.4T 5.8T 649G 91% /mnt/user0 shfs 6.4T 5.8T 649G 91% /mnt/user
Here's the mount locations:
# mount proc on /proc type proc (rw) sysfs on /sys type sysfs (rw) /dev/sdd1 on /boot type vfat (rw,noatime,nodiratime,umask=0,shortname=mixed) /dev/sdc1 on /mnt/cache type reiserfs (rw,noatime,nodiratime,user_xattr,acl) /dev/md1 on /mnt/disk1 type reiserfs (rw,noatime,nodiratime,user_xattr,acl) /dev/md2 on /mnt/disk2 type reiserfs (rw,noatime,nodiratime,user_xattr,acl) /dev/md4 on /mnt/disk4 type reiserfs (rw,noatime,nodiratime,user_xattr,acl) /dev/md5 on /mnt/disk5 type reiserfs (rw,noatime,nodiratime,user_xattr,acl) /dev/md3 on /mnt/disk3 type reiserfs (rw,noatime,nodiratime,user_xattr,acl) shfs on /mnt/user0 type fuse.shfs (rw,nosuid,nodev,noatime,allow_other,default_permissions) shfs on /mnt/user type fuse.shfs (rw,nosuid,nodev,noatime,allow_other,default_permissions) nfsd on /proc/fs/nfs type nfsd (rw)
Notice, there's no mount location for "/" included there, and nothing returned in df. That's why specifying / when calling df (to get "disk free" for root level directory) returns what it does:
# df / Filesystem 1K-blocks Used Available Use% Mounted on - 0 0 0 - /
So the reason nzbdrone can't see free space on / is because... such a thing doesn't exist as far as the OS is concerned. It's an oddity, but one I've been ignoring in my logs until now wherever it appears. Nice that it doesn't log an error anymore, and good to handle a circumstance where this happens (there's other scenarios in the linux world you might not be able to get free space for a given mount location), but not critical since if the unraid plugin has been configured properly you'll never be doing anything with / anyway, just mount locations underneath that.
-
Dragonfyre13, i posted a question on nzbdrones forum and markus answered it but it was a little cryptic for me. this the convo http://tinyurl.com/mvw53xf
can you tell me how you address this or this is a new weird thing.
thanks
That link doesn't seem to work for me. Just goes to "hp%20p400%20array%20controller". If you want to post the whole link here, I can take a look though.
-
New version up (v0.7) which fixes mediainfo usage. Apparently wasn't grabbing libmediainfo and libzen before, this version adds those as dependencies. Running "mediainfo" from the commandline shouldn't bomb out anymore, and nzbdrone should be able to use mediainfo as well.
-
Cool just had to share, the easiest update ever
root@LahomaMediaCenter:~# /etc/rc.d/rc.nzbdrone update
cat: /var/run/nzbdrone/nzbdrone.lock: No such file or directory
NzbDrone not running.
Installing latest version of nzbdrone from http://update.nzbdrone.com/repos/apt/debian...
Latest nzbdrone version is 2.0.0.1141, downloading deb from http://update.nzbdrone.com/repos/apt/debian/pool/main/n/nzbdrone/nzbdrone_2.0.0.1141_all.deb with MD5 of d49249035155b2ab30fca896493d2870
--2014-02-21 08:21:21-- http://update.nzbdrone.com/repos/apt/debian/pool/main/n/nzbdrone/nzbdrone_2.0.0.1141_all.deb
Resolving update.nzbdrone.com (update.nzbdrone.com)... 192.73.239.101
Connecting to update.nzbdrone.com (update.nzbdrone.com)|192.73.239.101|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 3775758 (3.6M) [application/octet-stream]
Saving to: `/tmp/nzbdrone.deb'
100%[======================================>] 3,775,758 1.14M/s in 3.3s
2014-02-21 08:21:24 (1.10 MB/s) - `/tmp/nzbdrone.deb' saved [3775758/3775758]
MD5 of http://update.nzbdrone.com/repos/apt/debian/pool/main/n/nzbdrone/nzbdrone_2.0.0.1141_all.deb is valid, extracting relevant files /mnt/user/appdata/nzbdrone
... OK
cat: /var/run/nzbdrone/nzbdrone.lock: No such file or directory
Removing stale lock file from previous execution.
Starting NzbDrone: sudo -u nobody mono-service /mnt/user/appdata/nzbdrone/NzbDrone.exe -d:/mnt/user/appdata/nzbdrone -l:/var/run/nzbdrone/nzbdrone.lock
1... OK
root@LahomaMediaCenter:~#
Awesome, like to hear the appreciation!
Also, there's now a button in the latest version (on the web UI) that actually calls that command from PHP to make it easier. Now you don't even need to telnet/SSH in, even though I generally am anyway.
Also note, once you copy the new plg file over the old one, the web UI for NZBDrone configuration should show version 0.6 as the plugin version. If it doesn't that means the new plugin version isn't installed. Make sure you run "installplg nzbdrone.plg" on the plugin after putting it into the /boot/config/plugins directory. Alternatively, you can always drop the plg file into that directory and reboot unraid, it will auto-install/update on unraid reboot as with any plugin.
-
Of course, I make a quick fix after releasing v0.5.
For the ONE person that grabbed it before I stuck out v0.6, go pull the new one down if you have issues. The only change is that it now forces the right permissions for the running user for a config directory existing outside the install directory (specifically after it is auto-moved from the config directory being inside the install directory).
LOLZ, at least i never installed it. Muahhahaa I have the only known copy of .5 to ever exist in the wild.
Cherish it forever, it's one of a kind. Or, you know, throw it away. Whichever.
-
Of course, I make a quick fix after releasing v0.5.
For the ONE person that grabbed it before I stuck out v0.6, go pull the new one down if you have issues. The only change is that it now forces the right permissions for the running user for a config directory existing outside the install directory (specifically after it is auto-moved from the config directory being inside the install directory).
-
OK guys, give that a shot. I just put v0.5 up there with a number of changes (think I've got most everything needed done except mono3.x usage/installation due to glibc incompatibility).
Tried using LD_PRELOAD for glibc usage without overriding the main glibc installation, but that didn't go to well so I'm going back to the drawing board.
-
To do the updates for nzbdrone when using the plg do you still just update it the same way you would any linux variant?
I just ran "/etc/rc.d/rc.nzbdrone update" from terminal and it updated to 2.0.0.1127 from 2.0.0.1073.
FYI - that's exactly what was intended. Latest version has an "update" button on the webUI if NZBDrone isn't running also. Should have latest up tonight sometime.
-
Darnit, you guys are right. I'll upload latest version tonight, even without Mono 3 being setup. Means we'll still have the issue of shutdowns after a few days or weeks of running, but a number of other things will be fixed.
-
That's... somewhat aggravating. Have a new version I wanted to include Mono 3.0 in, but appears slackware 13.37 uses glibc 2.13, not 2.11. Not sure if unraid just hasn't updated glibc in some time or what, but it's unfortunate nonetheless.
I've got a new version that handles nzbdrone updates nicely, among a few other things (should fix the known annoyances above at least). Want to see if I can get Mono 3.0 to be used first though, and without a glibc upgrade from 2.11 to 2.15 if I can help it.
-
Wow, so now we basically have nzbdrone for unraid. Just a couple of questions though, when a future plugin is released where the install directory and data directory is changed, will we have to move around the files ourselves?
I'd expect a default to be set for relative location of ./AppData, but it all depends on how it's implemented. Worst case you may need to back up your AppData directory (thus, the db as sparkysplace noted) and restore after doing the upgrade. I'll note it in the changelog when that's needed (if it's needed) though.
And sparkysplace, regarding the port, do you mean we are only able to change the port by editing the config file but not the UI for now?
If these two are the only issue with the plugin, it's really a fantastic news!
Port can be changed within the application, but it can't be changed currently within the plugin configuration.
Btw, will there be any issues with running mono 3.2.3 from the slackware 14.0 directory? Because Markus seems to be recommending version 3.0 to avoid nzbdrone crashing while adding many shows at once.
Not sure. I can investigate to find out though! I'll put it on the todo list to checkout if running mono 3.x with unraid 5.x is possible.
-
Updating with a fix for handling a stale lock file (actually shows if it's running or not now, rather than simply if there is or is not a lock file present).
Also, appears there's a tar.gz file with latest master up here. Means parsing out the deb file shouldn't be required, though that also means we lose out on an MD5 from Packages being checked, as well as version number being present (it'll only use latest master): http://update.nzbdrone.com/v2/master/latest/
-
The following are fixed in v0.2, attached to original post above (here: http://lime-technology.com/forum/index.php?topic=30463.msg282500#msg282500)
Gave it a try, when I try to install it says "NzbDrone.exe not found after installation, aborting" or something along those lines. I'll give it a proper looking at now.
Had to add the binutils package (for ar, required to unarchive the deb file) to the plugin. Installation should work now, please let me know if it still fails.
If it does still fail for some reason, would you mind opening a terminal and running "/etc/rc.d/rc.nzbdrone install" as root and giving the output that appears?
So if I'm not using any other plugins that use sqlite then I should either add it to this plugin or stick it in /boot/extra?
Grab the latest plugin, it's got sqlite3 in there as a dependency.
Don't put it in the extra folder. Add it to the plugin. It is easier for the user and the way every other plug in works. My plug in uses sqlite if you want to copy the lines instead of looking for everything.
Thanks, shamelessly stole the lines from your plugin and added the MD5 to them for validation too.
Seems you forgot the "ar" package in the plg. ar does not come with unraid by default, so we'll need to add this to the plg:
Yep, and thanks for the xml, saved me from digging for it myself and trying to figure out one to stick in there. Didn't know slackware latest package would work without conflict (since unraid is based on 13.37 AFAIK) but seems to work nicely.
Also, if you're installing as "nobody" the $RUNAS_HOME variable will end up being /, which means the script tries to create //.config. So it will NEED to be run as root when installing the plugin (it has no permissions to create /.config if run as nobody).
The problem was that I wasn't actually trying to create $RUNAS_HOME/.config, I was always trying to create /root/.config. Fixed now, you can run as whatever user you want (starting the service is run as root, which does have permissions to create /.config and chown to the RUNAS user.)
-
I'm using SB to dl TV shows. What does this new plugin do that SB can't?
I'm trying to keep the number of plugins to as few as possible - at least until the entire unraid plugin stuff is sorted out by Tom.
Biggest difference is that it handles thexem integration out of the box IMHO. That means it can actually download specials, American Dad, etc. on a regular basis. I'm still testing it out, but getting really tired of the performance on SB backlog handling, and on not being able to pull numerous shows. Inability to blacklist failed downloads in SB is frustrating as well, something nzbdrone fixes also.
It's certainly in the same space as SB, right now I'm using both while testing out the plugin and trying to determine what failings nzbdrone has that SB does better. So far haven't found much except that nzbdrone is new(ish) to linux, written in .NET, and handles finished downloads by watching a directory rather than through a completion script in SAB+ (takes about a minute from finish time to being moved into the final directory). All in all, pretty minor so far, except there's bits and pieces I don't yet understand how they work. Much better UI too.
-
Great feedback guys. Updated the plg with binutils (ar), sqlite3 and also put in mediainfo (based on a warning message I noticed in the nzbdrone log).
Testing things out now and I'll replace the attachment on the original post (here: http://lime-technology.com/forum/index.php?topic=30463.msg282500#msg282500)
About installing as "nobody", I'll test that out again too. My understanding is that when $RUNAS_HOME is determined (and created in nzbdrone_install) the script is running as root. That's why I need to pull it out of /etc/passwd rather than simply referencing $HOME env variable from the shell (I need a potentially different users home directory, not the current users).
-
Influencer, I've got a plugin here for nzbdrone (based heavily off your nzbmegasearch plugin since it's what I had handy). Perfectly willing to let you take it over. Maintainence should be minimal, since it's pulling latest deb from the official repo based on Package file in the repo index.
http://lime-technology.com/forum/index.php?topic=30463.msg282500#msg282500
-
If anyone wants to give it a shot, I wrote up a plg file for my own use. Attaching it here. It's a somewhat heavily modified version taken from Influencer's nzbmegasearch plg, since it's what I had handy (just installed that too).
Current status:
Will auto-configure for latest deb info, pulling latest deb file/version/MD5 from the official repository, to stay in sync with any updates to nzbdrones official linux download location. Pulls the package down, unarchives and then un-tar-gzips just the data required to the defined install directory. Ability to set config directory differently from install directory is experimental, you should DEFINATELY back up your AppData directory if you're upgrading, but appears to work (default just has nzbdrone config underneath install directory in "AppData").
Follows the info/instructions posted here by the way, and uses mono-service to run it properly. includes all the rc script goodness, including doing an install/update of the package from the rc script (pulling from latest in debian repo). Also includes auto-install of the mono dependency as well as mediainfo, sqlite and others (includes binutils/ar for handling install by yanking out of official deb package).
P.S. Perfectly fine if Influencer wants to take this over.
Changelog
v0.1:
- Initial creation, based off nzbmegasearch plugin
- Missing port configuration in plugin web interface
- Missing separate config directory configuration, always stores under installation directory
v0.2:
- Updated the plg with binutils (ar), sqlite3 and also put in mediainfo.
- Fixed a bug with version number being pulled into the web interface
- Fixed bug creating .config directory under home of RUNAS user, was always trying to create in root home instead
- Not sure why yet, but queue is now working with the modifications made to this version. Previously was spotty.
v0.3:
- Now actually respecting the lockfile, showing status based on status of the PID in the lockfile instead of assuming the service is running simply because there's a lockfile present.
v0.4:
- NOTE: Unreleased test version attempting to utilize mono3.x from a chroot environment automatically (did not go well). Kept in version history due to addition of changes for below
- Added update button to UI if NZBDrone is stopped
- Allow update of port number for NZBDrone from config UI
- Link NZBDrone in config UI, allow clicking of "started" to go directly to running instance
- EXPERIMENTAL!! ability to change AppData location to outside NzbDrone installation folder. Upgrade path from non-custom location is to blow away old AppData folder, do not use yet.
- AppData location takes relative path to install directory or full path to any other directory. Determining full path from relative path is currently a bad hack, but appears functional.
v0.5:
- Rolled back changes for v0.4 regarding Mono3.x usage. Continuing to use Mono2.x on unraid 5.x version (based on Slackware 13.1)
- Minor tweaks to hopefully make AppData location better handle upgrades from versions without custom AppData location specified. Recommend backing up AppData before plugin upgrade.
- AppData directory usage outside installation directory is experimental, backup NzbDrone configuration directory before changing it.
- If upgrading from previous version, may need to save existing config via web UI before modifying anything and saving will "stick" due to stored plugin config file changes.
- Removed MD5 requirement for NZBDrone logo, not needed and started breaking the plugin.
v0.6
- Fixed potential permissions issue causing wrong over after moving config directory outside install directory.
v0.7
- Added libmediainfo and libzen to dependencies, preventing mediainfo from properly running after install (dependencies for slackware 13.1 here, using 13.37 packages for nzbdrone but should find out if all really needed, runs fine on my system)
- Initial creation, based off nzbmegasearch plugin
-
They actually are already shut down at that point. Even shutting them down manually doesn't solve the unmount issue, it simply hangs (not entirely sure why)
-
Nope, I still see them there, and can pull them down. Let me know if you still can't access, probably something you need to reach out to a forum mod about though.
-
Right now, if I attempt to unmount my array, something seems to be running on my cache drive still. Not sure what it is, I can't identify it with fuser or lsof. Regardless, when I attempt to stop the array it inevitably has led to either a reboot (I killed to many things trying to get the file to be closed on the cache drive) or a manual umount from the commandline.
Right now, it seems that just "umount /mnt/cache" is being run to unmount the cache drive, as well as the others. Is it possible to add in if after a handful of tries they still don't unmount, to do a "umount -l" (which will unmount it gracefully, not allowing any new files to be opened, but old files will be closed by their owners before unmounting)
It seems to be a logical trade off. If you're stopping your array, you want it down. If you can't bring it down, there's not a lot of options other than a reboot while setting the array to not auto-start.
Any ideas/feedback?
-
OK, here I go resurrecting an old thread, but this one isn't exactly a "currently relevant" thing. Still useful.
"There, I fixed it". Big mario fan, have had this sitting around for some time, think I originally did it based off of sheet music or something. This has proper delays and durations in it, the one above just blasts along. Just put it into my go script as the last line, to notify me when everything is done.
beep -f330 -l138 -n -f330 -l275 -n -f330 -l138 -D138 -n -f262 -l138 -n -f330 -l275 -n -f392 -l550 -D550 -n -f262 -l413 -n -f196 -l138 -D275 -n -f164 -l275 -D138 -n -f220 -l275 -n -f247 -l138 -D138 -n -f233 -l138 -n -f220 -l275 -n -f196 -l206 -n -f330 -l206 -n -f392 -l275 -n -f440 -l275 -n -f349 -l138 -n -f392 -l138 -D138 -n -f330 -l275 -n -f262 -l138 -n -f294 -l138 -n -f247 -l413 -n -f262 -l413 -n -f196 -l138 -D275 -n -f164 -l275 -D138 -n -f220 -l275 -n -f247 -l138 -D138 -n -f233 -l138 -n -f220 -l275 -n -f196 -l206 -n -f330 -l206 -n -f392 -l275 -n -f440 -l275 -n -f349 -l138 -n -f392 -l138 -D138 -n -f330 -l275 -n -f262 -l138 -n -f294 -l138 -n -f247 -l413 -D275 -n -f392 -l138 -n -f370 -l138 -n -f349 -l138 -n -f311 -l275 -n -f330 -l138 -D138 -n -f207 -l138 -n -f220 -l138 -n -f262 -l138 -D138 -n -f220 -l138 -n -f262 -l138 -n -f294 -l138 -D275 -n -f392 -l138 -n -f370 -l138 -n -f349 -l138 -n -f311 -l275 -n -f330 -l138 -D138 -n -f523 -l275 -n -f523 -l138 -n -f523 -l550 -n -f392 -l138 -n -f370 -l138 -n -f349 -l138 -n -f311 -l275 -n -f330 -l138 -D138 -n -f207 -l138 -n -f220 -l138 -n -f262 -l138 -D138 -n -f220 -l138 -n -f262 -l138 -n -f294 -l138 -D275 -n -f311 -l275 -D138 -n -f294 -l275 -n -f262 -l550
-
1
-
-
Pretty sure I'm talking to myself at this point, but here's my search criteria for nzbmatrix:
+720p +- 1080p +- xvid
That chooses 720p or 1080p or xvid. The search criteria MUST be filled, and it MUST start with a plus. Not sure why, but that's the way it works.
-
Quick update made to the unmenu package to properly detect started/stopped state of moviegrabber. Used to always see it as started...
Also updated post name, since it's the 11th not the 10th. That was a dumb move.
[PhAzE] NZBDrone Unraid 5/6 plugins
in 6.0 (Unverified)
Posted
Nice job PhAzE! Thanks for the reference, and for doing the heavy lifting for mono-3.x on Unraid 5. I'll be trying out your plugin hopefully this weekend.
Unless someone has an issue with it, I'll plan to cease maintenance on my version of a plugin in preference to this one, assuming I don't find something breaking wrong with it (even then, it'll likely be an upstream patch submission to PhAzE instead).