John_M

The plugin's icon doesn't display in the Plugins page of the webGUI now that I've installed unRAID 6.4.0rc8q. I've tried un-installing and re-installing via Community Applications but that didn't help. It displays properly on unRAID 6.3.5. EDIT: I'm seeing this in my syslog: Sep 17 22:25:37 Mandaue nginx: 2017/09/17 22:25:37 [crit] 12080#12080: *4445 stat() "/usr/local/emhttp/plugins/snmp/snmp.png" failed (13: Permission denied), client: fe80::812:3b1f:ad19:da87, server: , request: "GET /plugins/snmp/snmp.png HTTP/1.1", host: "mandaue.local", referrer: "http://mandaue.local/Plugins" so it looks like a permissions issue. I'll investigate further. EDIT 2: The permissions of the /usr/local/emhttp/plugins/snmp directory are different from its siblings: drwxr-xr-x 7 root root 300 Sep 17 22:33 preclear.disk/ drwxrwx--- 2 root root 140 Sep 7 17:24 snmp/ drwxr-xr-x 6 root root 240 Jul 22 12:47 tips.and.tweaks/ meaning that only root can read its contents. Changing the mode to 755 fixed the problem but it will return when I reboot. I can't find what needs to be edited on the boot flash device. Perhaps the difference is that the old web server ran with UID root while nginx runs with a UID with fewer permissions?

Cyrillic text works in the preview for the forum - I won't prove to myself whether posting works until I click Post though. I've rsync'd these files between unRAID servers and the names are preserved - mover respects them too. -rw-rw---- 1 nobody users 4924819 Oct 6 2009 09\ ?\ ??\ ?\ \ (All\ The\ Things\ She\ Said).mp3 -rw-rw---- 1 nobody users 6462905 Oct 6 2009 10\ \ ??\ ????\ (Not\ Gonna\ Get\ Us).mp3 They also work with the macOS Finder. EDIT: Nope, it doesn't work when you click Post, but it does work with Preview.

I find that it misses the occasional new file too (and I've mentioned it here before). I think files get missed if the system is especially busy - ifnotify can only track so many items. I did suggest that when it is detected that some file is missing a checksum it would be nice if the automatic calculation of it could be triggered. I don't personally use the export feature, just the self-contained checksums. So on a good day I see a row of green ticks and a row of blue crosses.

I use it in preference to the stock syslog viewer because it's more customisable (I find the red (error) and the orange (login) highlights too similar in the built-in viewer) and because it has better filtering and therefore fewer false indications.

If you choose to retain the BIOS (by including "-b mptsas2.rom" in the sas2flsh command) is there anything you need to change from the default within the card's BIOS to prevent the system looking for attached bootable drives?

I've had the dashboard bookmarked this whole time. The simple point I'm trying to make is that it would be nice if this weren't necessary. If the UI is doing one thing, and lots of users are doing another, that would imply the UI could do with a change, hence the original post. I'm not looking for other solutions, I'm simply suggesting something that might be useful, hence "feature request". You'll find that people here do offer other suggestions, in the hope of being helpful. Often they turn out to be useful but if not to you then maybe to someone else. If they don't meet your particular requirements you can simply ignore them or maybe replay with, "Yes, thanks. I'd already thought of that."

I... could... But that's a little like: "My car doesn't have doors" "You could simply add your own" Not really. I was simply suggesting you might like to climb inside through the window instead of waiting in the cold for the manufacturer to turn up with those doors.

How much RAM do you have?

I updated to the latest version but I notice that the appdata/ripper/ripper.sh didn't get updated when I started the container. I had anticipated that it would and had backed up my edited version of your previous script so that I could refer back to it if necessary. I guess I need to delete ripper.sh to ensure it's re-created on docker start. Anyway, at the moment I'm still running with my tweak of your original script but as I only changed the CD section it doesn't prevent me from giving you the startup log that you asked for: As you'll see it ripped a CD (18 tracks) and encoded it in 12 minutes and it ripped a DVD (6.8 GB) in 17 minutes. Is there anything else I can help you with - anything from the big appdata/ripper/Ripper.log for example? I notice there are a lot of messages from MakeMKV regarding the DVD rip. They look like errors but I think it's MakeMKV trying different methods to access the data before settling down. So how useful do I really find it? Well, there's now a stack of CDs next to my server and whenever I walk past it I pop another one in. It just works. Again, many thanks for sharing.

That's great. Thank you.

The most recent update for this plugin is dated 2016.09.20, so no, it hasn't.

Both are quite normal, though, as you say, a little confusing. You can run the balance manually (e.g. to change the RAID level).

You could simply bookmark http://tower/Dashboard

From the appdata/ripper/Ripper.log file, it seems that cddb returned a unicode character instead of the left square bracket in one of the query responses: and somehow ripit converted it into two unprintable ASCII codes: EDIT: I spent the afternoon playing and here's what works for me: STORAGE_CD="/out/Ripper/CD" /usr/bin/ripit -d "$DRIVE" -o "$STORAGE_CD" -c 0,2 -b 320 -W -w --comment cddbid -D '"$suffix/$artist/$album"' -e --infolog "/log/autorip_"$LOGFILE"" -Z 2 -O y --playlist 0 --nointeraction >> $LOGFILE 2>&1 It fixes all the issues I've mentioned. I've decided to keep the .wav files (-w) for the time being as I have plenty of space, but I have no use for the .m3u files.

I've only tried it on CDs and, well... it works! I didn't realise that it was completely automatic at first, with no user interaction possible or required. But I also see that what is actually running is a script, ripper.sh that's located in the appdata/ripper folder. A couple of observations. I notice that to create an MP3 and a FLAC the CD is actually read twice. I watched it in progress - each track is ripped to a .rip file, which is renamed to a .wav. The .wav file is then encoded to MP3 and deleted. Then the process is repeated for FLAC. I see that the whole process of ripping, cddb requesting, naming and encoding (does it handle id tagging too?) is controlled by /usr/bin/ripit, which in turn is called once for MP3 and again for FLAC. I'm not familiar with ripit but I've been reading a man page for it http://man.cx/ripit(1). I'm not sure it's the correct version because you use a couple of options that it doesn't document, namely the -O and the --uppercasefirst options. I'm not sure what -O y does but I can guess that --uppercasefirst forces the names of tracks and artists to have capital letters at the beginning of all words. This may well be the cause of this minor naming issue: where it also appears to force the capitalisation of letters following an apostrophe, as in "Ruby, Don'T Take Your Love To Town" and "Daddy'S Eyes". Maybe this is a limitation of ripit. A little more serious is this one: where in tracks 17 and 18 a left square bracket character is getting substituted with a pair of unprintable characters, making the files invisible within the unRAID GUI. I renamed them manually. Both naming issues are minor and seem to be a feature of ripit, rather than your code, but it would be nice to fix them and also to avoid the need to read the CD twice. I notice that ripit allows multiple codecs to be specified so that looks like a way of avoid the need to rip twice, at the expense of probably having to sort the .flac and .mp3 files into their respective folders afterwards. Am I correct in thinking that once the docker is run for the first time and ripper.sh has been copied into the appdata/ripper folder it is static and if I want to experiment I can simply edit it there? My verdict, then: essentially, it works. Not only that, it works well enough to be useful. So well done and thank you.

I'm interested in Ripper. I've been using the MakeMKV docker for ripping DVDs and Blu-rays but I currently have nothing to use on CDs. I'll have a play with Ripper. Thanks for sharing.

Why? Because people asking for help often forget to include it and when requested manage to attach the wrong file. lol Everyone forgets to include it, and when they do Trurl et al bug them that there's no reason to include it, because diagnostics already includes it (but with troubleshooting mode, the syslog.txt will contain up to 30minutes more logging than the last diagnostics) All the more reason to give it a slightly different name. If I'm trying to help someone and I want to see the log for that last 30 minutes, the last thing I need is a copy of the syslog I already have from the diagnostics zip. Any chance you could take a look at this thread, please? I'm confused.

Why? Because people asking for help often forget to include it and when requested manage to attach the wrong file. lol Everyone forgets to include it, and when they do Trurl et al bug them that there's no reason to include it, because diagnostics already includes it (but with troubleshooting mode, the syslog.txt will contain up to 30minutes more logging than the last diagnostics) All the more reason to give it a slightly different name. If I'm trying to help someone and I want to see the log for that last 30 minutes, the last thing I need is a copy of the syslog I already have from the diagnostics zip.

Why? Because people asking for help often forget to include it and when requested manage to attach the wrong file.

Hi Squid, is there any chance the troubleshooting syslog that's saved to the boot flash could be given a slightly different name to distinguish it easily from the other syslog that's contained within the diagnostic zip, please?

Hmmm... I haven't been able to spot anything amiss and Googling the error message doesn't reveal very much. It may well be benign.

System Profiler plugin (2016.11.06) is reporting the P+Q algorithm incorrectly with unRAID 6.3.0-rc9: It seems to be parsing my syslog incorrectly: EDIT: It looks as though the newer kernel is reporting avx differently. Here's the equivalent snippet of syslog from a different server (same chipset but different processor) running unRAID 6.2.4:

I did a search and found a recent question about something very similar. Unfortunately, it elicited no replies. I don't know if it's related in any way to this. Post your diagnostics (Tools -> Diagnostics) and we'll have a closer look.

I first mentioned this twelve pages ago. Whoops, sorry about that . I did read back several pages in the thread, but admittedly could have searched for "Safari". Thx for pointing out this has already been identified. I'm pleased that someone else mentioned it, actually. Browser issues often get overlooked, especially when they affect only a small minority of users.

I first mentioned this twelve pages ago.