unRAID Server Release 6.1-rc3 Available

manually created on the cache drive

That's the problem.  Or rather, the fact we let you do that via docker and vm manager is the problem.  We are tossing around ways to fix this.

Thanks. It's one thing for someone to do this at the command line, but having the GUI let or even encourage people to do it has caused all sorts of havoc, which can often only be fixed at the command line, sometimes after pages of discussion.

I have read all the replies in this thread about notifications. In fact, I even searched the thread for "notif" just to make sure I hadn't missed something.

 

I did the re-enable of my notifications, and that seems to be working to some extent, because I am getting the daily Array status notification.

 

However, I don't seem to be getting some notifications that I used to get. For example, I replaced a disk with a larger one, and I didn't get anything about that, including a notification when the rebuild had finished. When I did something similar just before this RC, I did get an email when the rebuild started and when it finished. These sorts of notifications should have happened as one of the "Notification entities"; i.e., Notices, Warnings, Alerts.

 

Also, I have some scripts which have a line to send notifications. For example

/usr/local/sbin/notify -i normal -s "Cache Drive Backup Completed" -d " Cache Drive Backup completed at `date`"

but I see that /usr/local/sbin/notify no longer exists.

 

I just started a parity check since my rebuild just finished and no notification of that either. Looking at the syslog after starting my parity check, I see these lines

Aug 14 09:52:03 unSERVER php: /usr/local/emhttp/webGui/scripts/notify cron-init
Aug 14 09:52:25 unSERVER kernel: mdcmd (32): check NOCORRECT

so it looks like notify has been moved to /usr/local/emhttp/webGui/scripts/notify, but why is it doing cron-init, and why do I not get a notification as a result of this notify?

Also, I just remembered to test this

When changing the banner, it should store the file banner.png under folder /boot/config/plugins/dynamix.

 

The code is missing to copy the banner file from flash to RAM upon system restart. I do the following in my go file

# Copy custom banner
if [[ -s /boot/config/plugins/dynamix/banner.png ]]; then
  cp /boot/config/plugins/dynamix/banner.png /usr/local/emhttp/webGui/images
  chmod -x /usr/local/emhttp/webGui/images/banner.png
fi

The restrictions are [1] file must be png format, and [2] max file size is 100KB (warning is given when conditions are not met).

 

This is also in the rc.local file I missed adding to the -rc1 release.

 

I also increased max file upload to 600KB for both thumbnails and banner.

 

Ideally for thumbnails you want 48x48 pixels; for banner 1270x90 - whatever images you specify will scaled to these dimensions upon display.

 

The file extension needs to be .png but most browsers will display correctly if they are actually .jpg in disguise.

After reducing color depth to 8 I was able to make it work with drag-drop.

 

To summarize, my original attempt was with png of 1270x90x32=217KB, and that didn't save to flash, no warning.

 

I reduced it to 1270x90x8=52KB and that did save to flash and updated my banner in the GUI.

 

I assume I must put bonienl script in go for it to survive a reboot until next release, and then I will try again with my 1270x90x32 png.

and it still won't let you use a banner larger than 100KB.

manually created on the cache drive

That's the problem.  Or rather, the fact we let you do that via docker and vm manager is the problem.  We are tossing around ways to fix this.

Thanks. It's one thing for someone to do this at the command line, but having the GUI let or even encourage people to do it has caused all sorts of havoc, which can often only be fixed at the command line, sometimes after pages of discussion.

 

I had suggested this before, but I will again. Perhaps it is one of the ideas already being tossed around.

 

For Dockers, the "appdata" folder is considered best practice. Most (all?) Dockers default to this for their config locations. Maybe its time to add some logic to the docker init that if a cache drive is present, an appdata share is automatically created and set to cache-only? Or a pop up asking is the user would like unRAID to setup the appdata share for them, so they could opt-out and do it manually?

... and it still won't let you use a banner larger than 100KB.

 

The size limitation comes from the internal way emhttp is working and doesn't allow for files larger than 95KB. Works are in the pipeline to overcome this limitation, but it won't come in v6.1

 

... and it still won't let you use a banner larger than 100KB.

 

The size limitation comes from the internal way emhttp is working and doesn't allow for files larger than 95KB. Works are in the pipeline to overcome this limitation, but it won't come in v6.1

 

The limit is actually 95K for file upload via browser.  But you can copy any size image you want manually to your flash, saving it to

config/plugins/dynamix/banner.png

... and it still won't let you use a banner larger than 100KB.

 

The size limitation comes from the internal way emhttp is working and doesn't allow for files larger than 95KB. Works are in the pipeline to overcome this limitation, but it won't come in v6.1

 

The limit is actually 95K for file upload via browser.  But you can copy any size image you want manually to your flash, saving it to

config/plugins/dynamix/banner.png

Thanks. That seems to work.

 

Any thoughts on my notification issues?

Any thoughts on my notification issues?

 

There is a reference error in the monitor script, it should read:

 

$notify = "/usr/local/emhttp/webGui/scripts/notify"

 

Hence a number of notifications is broken in v6.1-rc3.

 

 

Any thoughts on my notification issues?

 

There is a reference error in the monitor script, it should read:

 

$notify = "/usr/local/emhttp/webGui/scripts/notify"

 

Hence a number of notifications is broken in v6.1-rc3.

Thanks. I have patched on my system.

Any thoughts on my notification issues?

 

There is a reference error in the monitor script, it should read:

 

$notify = "/usr/local/emhttp/webGui/scripts/notify"

 

Hence a number of notifications is broken in v6.1-rc3.

 

This as well as other notifications fixed for -rc4.

Guys,

 

Given you're implementing new features, such as a customisable banner, shouldn't we look to future proof the code? It would be great if the images could be HDPi for example, currently the stock banner and graphical elements look pretty ugly on my Retina displays.

 

I have noticed that most plugins now include @2x images, so change is afoot.

 

Just a thought.

Please post this in the Roadmap board.

Had a powercut last night (actually, according to my email notifications, there were two powercuts, 29 minutes apart) for the first time since installing rc3 and powerdown v2.18.  Notifications worked fine, but the shutdown was unclean, resulting in a parity check on restart.  Also, no logs were stored so no means of working out what went wrong.