unRAID Server Release 6.1-rc1 Available


Recommended Posts

Has Unassigned devices stopped working in 6.1rc1?

 

The display is not working,  anything you had to auto-mount is still working (  i just checked mine and my auto-mounts are fine ),  you just cant see anything if you have to manually mount something

 

I had some problems with editing shares as well, can't test as I've had to roll back to V6.0.1 as my TBS DVB drivers won't compile on kernel 4.1.1.  :-[

Link to comment
  • Replies 114
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Posted Images

Another notable addition to this release is the inclusion of the "OpenELEC" template type in VM Manager.

 

It may be prudent to note in the OP which version of OE is being pulled (latest stable, latest beta/RC, legacy stable, user choice, etc.)...especially for those that are using a shared mysql database.

 

Also, how are OE upgrades handled?

 

Nice work!

 

John

The version number is indicated in the webgui before you download and create a VM, so don't think we need to mention that in the OP. For those curious, its just OE 6.0.0 beta 2 for right now.

 

Upgrades are handled by downloading a new image file when we release it and then starting the VM. Same config folder used.

Just fyi, there is an openelec beta 3 now, which is based on kodi isengard rc2

Link to comment

Another notable addition to this release is the inclusion of the "OpenELEC" template type in VM Manager.

 

It may be prudent to note in the OP which version of OE is being pulled (latest stable, latest beta/RC, legacy stable, user choice, etc.)...especially for those that are using a shared mysql database.

 

Also, how are OE upgrades handled?

 

Nice work!

 

John

The version number is indicated in the webgui before you download and create a VM, so don't think we need to mention that in the OP. For those curious, its just OE 6.0.0 beta 2 for right now.

 

Upgrades are handled by downloading a new image file when we release it and then starting the VM. Same config folder used.

Just fyi, there is an openelec beta 3 now, which is based on kodi isengard rc2

Yeah, we saw that. Not sure if we will update the image to that before OE 6.0.0 final hits.

Link to comment

Played around a bit with the new "Enable disk shares" parameter.  Works pretty nice, but I did note that even if there are no cached shares, the cache drive is not exported.    I'd think if there are no shares using it, it would be desirable to be able to "see" it on the network.    [The parameter was set to "Auto"]

 

Personally, I'd prefer that the disk shares be effectively "Yes - Hidden" instead of "No" when they're participating in a share; but if I understand the underlying mechanism you described, the "No" actually eliminates the "user share copy" problem, so that's a very good rationale for it.

 

This will likely cause some complaints from folks who are trying to move data around their server ... but they can always change the setting to "Yes" and let it behave like it did before this release.

Actually they can just stop including a disk from global share settings. This let's them move data from the disk share to a user share.

Link to comment

Just updated my other v6 test server and had a thought (dangerous) ==>  it's very simply to just install a plugin to get on the "RC path" (as you've done for v6.1), but why not just add a checkbox by the "Check for Updates" button that says "Include Release Candidates".    This could either be persistent, or perhaps require checking it every time to ensure you've actively chosen to update to an RC.

 

Link to comment

Just updated my other v6 test server and had a thought (dangerous) ==>  it's very simply to just install a plugin to get on the "RC path" (as you've done for v6.1), but why not just add a checkbox by the "Check for Updates" button that says "Include Release Candidates".    This could either be persistent, or perhaps require checking it every time to ensure you've actively chosen to update to an RC.

 

Because that's a lot more work and we want people using -beta/-rc to at least be proficient enough to install a plugin manually.

Link to comment

@Tom: in rc.local change "notify init" to "notify smtp-init"

 

Yeah that fix is in my development server but somehow neglected to copy the file to release - doh!

 

Hey, I also put this code in rc.local:

# copy monitor.ini file
if [ -s /boot/config/plugins/dynamix/monitor.ini ]; then
  cp /boot/config/plugins/dynamix/monitor.ini /var/local/emhttp
  chmod -x /var/local/emhttp/monitor.ini
fi

 

But really, why can't a variation of this go into /usr/local/emhttp/plugins/dynamix/scripts/monitor ?  I don't want to continue polluting rc.local with these kinds of special cases.

Link to comment

Just updated my other v6 test server and had a thought (dangerous) ==>  it's very simply to just install a plugin to get on the "RC path" (as you've done for v6.1), but why not just add a checkbox by the "Check for Updates" button that says "Include Release Candidates".    This could either be persistent, or perhaps require checking it every time to ensure you've actively chosen to update to an RC.

 

Because that's a lot more work and we want people using -beta/-rc to at least be proficient enough to install a plugin manually.

Makes sense, was kind of what I assumed, the only problem with that is you won't get the quantity of people testing that perhaps you would with gary's suggestion, but you may get better quality reporting of errors.

 

One thought, are there really users who can't install a plugin? Really?!

Link to comment

Just updated my other v6 test server and had a thought (dangerous) ==>  it's very simply to just install a plugin to get on the "RC path" (as you've done for v6.1), but why not just add a checkbox by the "Check for Updates" button that says "Include Release Candidates".    This could either be persistent, or perhaps require checking it every time to ensure you've actively chosen to update to an RC.

 

Because that's a lot more work and we want people using -beta/-rc to at least be proficient enough to install a plugin manually.

Makes sense, was kind of what I assumed, the only problem with that is you won't get the quantity of people testing that perhaps you would with gary's suggestion, but you may get better quality reporting of errors.

 

One thought, are there really users who can't install a plugin? Really?!

 

back in the day i was a tech support for tulip computers (remember them ?, they used to sponsor crystal palace) the most common support question was why doesn't my monitor work...

there were two competing standards back then, despite there being in big letters on the front page of the manual, on the back of the card itself and on the monitor cord  instructions to flip a switch to change over standards, in the event of your monitor not working.

Link to comment

Just updated my other v6 test server and had a thought (dangerous) ==>  it's very simply to just install a plugin to get on the "RC path" (as you've done for v6.1), but why not just add a checkbox by the "Check for Updates" button that says "Include Release Candidates".    This could either be persistent, or perhaps require checking it every time to ensure you've actively chosen to update to an RC.

 

Because that's a lot more work and we want people using -beta/-rc to at least be proficient enough to install a plugin manually.

Makes sense, was kind of what I assumed, the only problem with that is you won't get the quantity of people testing that perhaps you would with gary's suggestion, but you may get better quality reporting of errors.

 

One thought, are there really users who can't install a plugin? Really?!

 

back in the day i was a tech support for tulip computers (remember them ?, they used to sponsor crystal palace) the most common support question was why doesn't my monitor work...

there were two competing standards back then, despite there being in big letters on the front page of the manual, on the back of the card itself and on the monitor cord  instructions to flip a switch to change over standards, in the event of your monitor not working.

You know, thinking about it I've read enough on r/talesfromtechsupport on reddit to know better.  Ok LT I get where you're coming from...

Link to comment

Agree.  There are many users who do not WANT to run Beta, or even RC, versions .... and while the auto-update feature is really nice, it indeed makes sense to limit it to stable version updates UNLESS somebody has intentionally "opted in" to a Beta or RC version via either a plug-in that then installs it automatically, or even by manually downloading it and updating the flash drive.    I was thinking a checkbox would serve that purpose as well; but after thinking about it, I agree that may be too simple => users often tend to just check boxes like that without really thinking about the potential implications.

 

Link to comment

Agree.  There are many users who do not WANT to run Beta, or even RC, versions .... and while the auto-update feature is really nice, it indeed makes sense to limit it to stable version updates UNLESS somebody has intentionally "opted in" to a Beta or RC version via either a plug-in that then installs it automatically, or even by manually downloading it and updating the flash drive.    I was thinking a checkbox would serve that purpose as well; but after thinking about it, I agree that may be too simple => users often tend to just check boxes like that without really thinking about the potential implications.

 

When -rc2 is published, you will be able to update from -r1 using the normal 'check for updates' method.  Let's say we end up publishing -rc2 then -rc3 and then finally 6.1.0 (stable).  If you have any of the -rc's installed when you check for updates, it will end up installing 6.1.0, getting you back on the 'stable' track.  If later we produce 6.2-beta1 or 6.2-rc1, again you will have to manually install the plugin via pasting the link to get onto the '6.2' beta/rc track.  After a 'stable' is released we'll leave the -rc plg file there for a while, maybe a week or so, and then delete them.  That means if you're running an -rc and do not check for updates in a timely manner it may result in you having to manually install the 'stable' plg file to get back on the stable track.

Link to comment

Hmmm ... while that process works, it does leave a few potential "holes" and also results in updates that not everyone may want.  Historically, many folks have installed SOME of the Beta or RC versions ... but not every one => often evaluating the release notes to decide whether or not to install the "next" version.

 

Perhaps the plugin you have to install to get the Beta/RC should always be a ONE-TIME use plugin ... i.e. copy the URL, install the plugin, do the Update check, and then install the update -- and the plugin "self-destructs" ... i.e. putting you back on the "stable" cycle, so the next update it will automatically install is the next stable release.

 

For those who want Beta/RC releases, it's simple enough to simply copy a URL from the announcement post (just like we all did for RC1) and install that plugin.

 

This would completely eliminate any chance of a "Beta by accident" install -- even for those who had installed an earlier Beta on purpose --  and would also ensure that nobody ever had to install a "stable" plg file to get back on the stable release track.

 

 

 

Link to comment

the new button structure has some problems.

 

I needed to update my gmail password on the SMTP settings, and because it is the last field and you need to leave the field before the apply becomes available I had to find another field to temp modify so it would ungrey as tabbling out of the password box would skip the greyed about apply button.

 

The Apply button needs to become avail and SOON as a field is changed, not when you leave the field

 

Myk

 

Link to comment

the new button structure has some problems.

 

I needed to update my gmail password on the SMTP settings, and because it is the last field and you need to leave the field before the apply becomes available I had to find another field to temp modify so it would ungrey as tabbling out of the password box would skip the greyed about apply button.

 

The Apply button needs to become avail and SOON as a field is changed, not when you leave the field

 

Myk

 

Easiest way of working is to press TAB after an input field is entered.

 

Link to comment

the new button structure has some problems.

 

I needed to update my gmail password on the SMTP settings, and because it is the last field and you need to leave the field before the apply becomes available I had to find another field to temp modify so it would ungrey as tabbling out of the password box would skip the greyed about apply button.

 

The Apply button needs to become avail and SOON as a field is changed, not when you leave the field

 

Myk

 

Easiest way of working is to press TAB after an input field is entered.

 

again, this does not work if the field you just modified is the last field on the page, hitting tab SKIPPS the apply button because it is still greyed out.  I had to modify another field farther up for the Apply button to ungrey and then set that field back before I hit the apply button.

 

Myk

 

Link to comment

again, this does not work if the field you just modified is the last field on the page, hitting tab SKIPPS the apply button because it is still greyed out.  I had to modify another field farther up for the Apply button to ungrey and then set that field back before I hit the apply button.

 

Hitting TAB will enable the Apply button which can be clicked subsequently, no need to change another field.

 

Link to comment

again, this does not work if the field you just modified is the last field on the page, hitting tab SKIPPS the apply button because it is still greyed out.  I had to modify another field farther up for the Apply button to ungrey and then set that field back before I hit the apply button.

 

Hitting TAB will enable the Apply button which can be clicked subsequently, no need to change another field.

 

Settings > Notification Settings > SMTP Settings > Click on Password field - Last field of the page, add a character to the end > hit Tab - Skipps Greyed out Apply Button and selects Done button instead

 

Myk

Link to comment

In regard to:

“Another change: all so-called 'hidden' objects - files/directories beginning with dot '.' character - are shown when viewing shares and also visible via SMB.  This makes it easier to see why a particular share is not "empty"”

 

Stored with all  my media shares (SMB) and sub-directories are a number of hidden (dot) folders of different uses.  These will now become visible and compromise the aesthetics on my themed WDTV media players.

The need for this change would appear to be an outlier “use case” for maintenance purposes.  If it is required then please make it a switchable option in the GUI.

Thank you.

Link to comment

Does 6.1 support the Altheros 8171 NIC?

Yes.

 

it would seem UnRAID doesn't have the driver?

What makes you say that?

 

All the Atheros (and Qualcomm Atheros) drivers are included except for the "Atheros L2 fast ethernet" driver - which is for old 100Mbit nics.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.