Upcoming moOde 8.2.1 release

[romain]

Also, for my own setup, I've repaced val("ro,nolock") by val("soft,timeo=10,retrans=1,ro,nolock") in /var/www/js/config.min.js

[Tim Curtis]

Right, there is no check for availability of the exports. If the export is not available then I assume the test (ls MOUNT_POINT) for the mount point would fail.

I'll look into having "soft,timeo=10,retrans=1,ro,nolock" should be the default NFS mount options.

[TheOldPresbyope]

Given that we’re talking about a moOde player mounting NFS shares from separate servers, it seems safe to use soft mounts. Maybe a mild warning in the docs to hacker-users who want to do things involving writes to those external NFS shares.

This discussion is dredging up old memories, and definitely not good ones, of trying to keeps a polyglot mixture of engineering workstations (Sun, HP, SGI, IBM) up and running with extensively cross-linked NFS. A long time ago, thankfully.

Regards,
Kent

[Tim Curtis]

Testing with "soft,timeo=10,retrans=1,ro,nolock" was successful.

I'll push a commit making this the default mount options for NFS.

[Tim Curtis]

Good news, Airplay 2 testing was successful :-)

Here are some screenies (reading from left to right)

(1) Select Moode (2), Select PB1, (3) They get combined into a single clickable item indicating  “2 speakers"

                 

(1) Now the song title appears instead of “2 speakers”, (2) Tap the Speaker icon to get the individual endpoints

         

[romain]

Tim,

since NFS mounts will no more be a problem and that my script does everything that mountmon.php but maybe more complete and works flawlessly, why not combine both and make mountmon.php call my script instead of executing simple shell commands ? It may require some adaptations but I don't think it would be too difficult to do.

Also, IMHO, though the led part of my script is much more useful than just decide to switch them on or off via system config, this can easily be removed.

It's just a suggestion.

[Tim Curtis]

I'm in the process of doing the release administration for 8.2.1 and so that ship has already sailed but maybe for next release it can be considered. Off the top of my head monitoring of USB mounts and LED indicators seems unnecessary.

I'm also trying to get to a point where all code is managed via Github processes. This is to help streamline our project management and administration.

Did you happen to put the code in a Git repo and is there a license attached?

[romain]

I'm in the process of doing the release administration for 8.2.1 and so that ship has already sailed but maybe for next release  it can be considered. Off the top of my head monitoring of USB mounts and LED indicators seems unnecessary.

I'm also trying to get to a point where all code is managed via Github processes. This is to help streamline our project management and administration.

Did you happen to put the code in a Git repo and is there a license attached?

Tim,

this code doesn't belong to any Git repo and there is no license attached to it. I've written it for my own use and even if it is used partially, I'll be happy to bring my humble contribution to moOde.

In my case, probably like many other moOde users too, my pi based DACs (one is the server with USB SSD attached to it, the other is the client) are enclosed in transparent cases so, if something goes wrong (i.e. music stops because network is disconnected, music shares become unavailable, server/NAS is rebooted, USB attached device has a problem, ...), I can immediately see it when green LED starts blinking without connecting to the interface.
In the same way, I can immediately see when things become normal again (shares are online, network is OK) with fixed green LED on and red LED off.
Another example is when I stop NFS and Samba daemons to do shell scripted automated backups from my moOde master device with USB attached to it to my NAS.

Have a nice day

[Tim Curtis]

I'm in the process of doing the release administration for 8.2.1 and so that ship has already sailed but maybe for next release  it can be considered. Off the top of my head monitoring of USB mounts and LED indicators seems unnecessary.

I'm also trying to get to a point where all code is managed via Github processes. This is to help streamline our project management and administration.

Did you happen to put the code in a Git repo and is there a license attached?

Tim,

this code doesn't belong to any Git repo and there is no license attached to it. I've written it for my own use and even if it is used partially, I'll be happy to bring my humble contribution to moOde.

In my case, probably like many other moOde users too, my pi based DACs (one is the server with USB SSD attached to it, the other is the client) are enclosed in transparent cases so, if something goes wrong (i.e. music stops because network is disconnected, music shares become unavailable, server/NAS is rebooted, USB attached device has a problem, ...), I can immediately see it when green LED starts blinking without connecting to the interface.
In the same way, I can immediately see when things become normal again (shares are online, network is OK) with fixed green LED on and red LED off.
Another example is when I stop NFS and Samba daemons to do shell scripted automated backups from my moOde master device with USB attached to it to my NAS.

Have a nice day

I get that visuals are important but in general failed mounts, networks and hosts are uncommon and so it could be easy to forget the blink codes over time, plus a lot of users have their Pi's tucked away or in opaque cases. The other challenge is that the Pi has a set of its own blink codes to indicate certain failure modes and this could create confusion.

If your intention is to have all or part of your code used by others then it must have a license that stipulates that the code can be freely redistributed by another project. Unlicensed works, but law cannot be redistributed. For reference moOde uses Open Source GPLv3 license so your code must be licensed in a way thats compatible with that license.

Creating a Git repo and assigning a license is easy :-)

[Nutul]

Creating a Git repo and assigning a license is easy :-)

Hi Tim,

I see all this mess of licenses, and the only thing I understand is that:

1. I own MY repository for MY projects, I write code there (licensed) and other people can come over, take the code, and incorporate it in THEIR projects: my code is "licensed" under LGPL or whatsoever, hence everything is fine on both sides; right?

2. I am a contributor of a project (in this specific case moode-player) and I do write code for it. I do not include any other licence to each and every file I may need to create in order to have my code-contribution work; right?

NOW, I do understand that "better-safe-than-sorry" applies almost everywhere, but... here we're talking about a bash script, performing specific LINUX commands. Linux has its own licence => you use Linux => you agree with that => everybody-is-happy. If the script is too much "RPi specific" then it will get included only on moode-for-RPi. 

Sorry, but I do hate bureaucracy, especially when it prevents me to improve my life, and that of others. Maybe we are pushing things too far, uh?
The code does not involve other people. It's brand-new code, and it does not infringe any, ANY copyright... (of course it doesn't, Linux is not copyright)
People can get frustrated, facing all this futile garbage, and we, as a community, may suffer for the loss of great contributions.

Moreover, moOde has already a licence. *You* agree to write code for it... case closed ;-)


Sorry once more, but it really gets me nuts! I could easily decide to keep my code for myself, and just patch each and every moOde release with my fixes; then build and deploy for my machine. Easy. But... Just my 2c for it, let's keep things fun, and "listen to the music" (cit. Hans Beekhuyzen)

Cheers, Al.