Tim if others can confirm that.
Maybe you can host the .sh and the .properties files.
Is this case, it could be a bit easier :
Log to pi
Check unzip is here (for example, it is not in VolumIO), if not apt-get
Plug an USB key to have enough space
Format it, Mount it on a working rep (mounting point)
Cd in it
pwd (copy the path)
wget .sh file
wget .properties
Edit .properties file to set MYPATH (paste the path)
sudo ./install_moOde.sh 2>&1 | sudo tee prep_moOde_log.txt
And that's all (except the moment for plugging USB SD writer & answering confirmation for writing SD ...
When prep is finish ... umount key, rm mounting point & power off
Swap pi sd card ... power on & just waiting.
I am looking to reduce boot (even if we don't have to expect to save a lot time)
Regards
Tim,
I got an idea on a full automatic build automation.
Let me expose if you can host on your server (install_moOde.sh & install_moOde.properties).
The idea is to write an other script that do :
- Advert user to backup his current SD card
- Ask user to unplug all usb device
- Verify if ther is enough space to work on SD
if no :
Ask to plug an USB drive to work on it with advert that everything will be delete on it
Detect the device of the key
format it
mount it
create mount point and go in it
if yes :
create directory and go in it
- verify unzip (for volumio)
- wget install_moOde.sh
- wget install_moOde.properties
- give execute right to install_moOde.sh
- Asking to plug SD card writer to detect it (save device in a file)
- launch install_moOde.sh
Like this, you can update moOde version, raspbian ... like you want by changing the properties file on your host server.
When this script is operational, just modify the interaction writing process to detect and write SD (with the dev detected before) on install_moOde.sh.
And host the 3 files.
And user has just to do :
wget this_new_script
chmod +x this_new_script
sudo ./this new_script
What do u think about this ?
Hi @watchtmouse,
Should be all set now. Amazon CDN caches have been invalidated making the newly uploaded files available.
In STEP 4, number 2 the error below can be ignored. There was already a NOTE to that effect in the recipe.
# sudo autoreconf --install
# aclocal: warning: couldn't open directory 'm4': No such file or directory
and I've removed the cmd below because that particular service file won't be created until later in the build.
# sudo systemctl disable bluealsa.service
# Failed to disable unit: No such file or directory
and I added the / to dev/null in STEP 9.
-Tim
Should be all set now. Amazon CDN caches have been invalidated making the newly uploaded files available.
In STEP 4, number 2 the error below can be ignored. There was already a NOTE to that effect in the recipe.
# sudo autoreconf --install
# aclocal: warning: couldn't open directory 'm4': No such file or directory
and I've removed the cmd below because that particular service file won't be created until later in the build.
# sudo systemctl disable bluealsa.service
# Failed to disable unit: No such file or directory
and I added the / to dev/null in STEP 9.
-Tim
Yes I can host the files at moodeaudio.org
I'm not sure I understand the first part. Sometimes its easier to work through something like this via email. tim at moodeaudio dot org
-Tim
No problem. I will email you tomorrow ( Bedtime routine for childrens hereYes I can host the files at moodeaudio.org
I'm not sure I understand the first part. Sometimes its easier to work through something like this via email. tim at moodeaudio dot org
-Tim
)Inplace upgrade is working on my test systems
Hi, The inplace update procedure is working well on my test systems (ß6 and ß7 - had to leave out ß8 for time issues).
@Tim:
There's a typo:
-----
If u want to examine the update package and its installation script before installing it then run the cmds below.
wget http://moodeaudio.org/downloads/update-r40b9.zip
unzip update-r40b8.zip cat ./update/install.sh
cat ./update/install.sh
----
Just for those who copy without reading....
-Josef
Hi, The inplace update procedure is working well on my test systems (ß6 and ß7 - had to leave out ß8 for time issues).
@Tim:
There's a typo:
-----
If u want to examine the update package and its installation script before installing it then run the cmds below.
wget http://moodeaudio.org/downloads/update-r40b9.zip
unzip update-r40b8.zip cat ./update/install.sh
cat ./update/install.sh
----
Just for those who copy without reading....
-Josef
Hi,
moOde 4.0 BETA 9 is available
- FIX: Sources screen hangs in certain scenarios
- FIX: Roaming between AP mode and WiFi SSID
- FIX: Cover art not displayed when same Title different Artist
- FIX: SSID Scan not returning anything in certain scenario
- FIX: Workaround for MPD not capturing BBC 320K bitrate
- UPD: Improved error reporting for failed NAS mount
There is also an in-place update for Beta 6/7/8 -> Beta 9.
It MUST be run from cmd line AND on an un-squashed /var/www !! The browser title will revert to "moOde Player" after the update. Use System config to change it, then APPLY MPD settings to get the new DoP param.
Also, BE SURE to backup /var/www and /var/local/www directories before applying the update in case you need to revert!
sudo /var/www/command/updater.sh r40b9
If u want to examine the update package and its installation script before installing it then run the cmds below.
wget http://moodeaudio.org/downloads/update-r40b9.zip
unzip update-r40b9.zip
cat ./update/install.sh
-Tim
Just a friendly Bump.
-TIm
Build Recipe v1.8
STEP 11 - Optionally, install latest Linux Kernel
This step would not work for me. Tried it twice. Two different errors.
STEP 13 - Final prep for image
The last copy in this step failed.
Cheers.
STEP 11 - Optionally, install latest Linux Kernel
This step would not work for me. Tried it twice. Two different errors.
Code:
pi@moode:~ $ sudo PRUNE_MODULES=1 rpi-update
*** Raspberry Pi firmware updater by Hexxeh, enhanced by AndrewS and Dom
*** Performing self-update
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- 0:00:19 --:--:-- 0curl: (6) Could not resolve host: raw.githubusercontent.com
!!! Failed to download update for rpi-update!
!!! Make sure you have ca-certificates installed and that the time is set correctly
pi@moode:~ $ sudo PRUNE_MODULES=1 rpi-update
*** Raspberry Pi firmware updater by Hexxeh, enhanced by AndrewS and Dom
*** Performing self-update
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 13403 100 13403 0 0 1245 0 0:00:10 0:00:10 --:--:-- 4132
*** Relaunching after update
*** Raspberry Pi firmware updater by Hexxeh, enhanced by AndrewS and Dom
*** We're running for the first time
*** Backing up files (this will take a few minutes)
*** Backing up firmware
*** Backing up modules 4.9.59-v7+
Invalid git hash specified
pi@moode:~ $ sudo rm -rf /lib/modules.bak
pi@moode:~ $ sudo umount /boot
pi@moode:~ $ sudo dosfsck -tawl /dev/mmcblk0p1STEP 13 - Final prep for image
The last copy in this step failed.
Code:
pi@moode:~ $ sudo cp ./rel-stretch/network/hostapd.conf.default /etc/hostapd/hostapd.conf
cp: cannot create regular file '/etc/hostapd/hostapd.conf': No such file or directoryCheers.
many thx again->here Beta9->for info:
with Generic 2 I2S-Hifiberry-DAC and chinese ES9028Q2M-board-> Dop-possible !
Hi,
This is a question for "chinese ES9028Q2M-board" manufacturer.
Do they make a device driver for their device that supports DoP over I2S?
-Tim
I got the impression that he meant it is possible. Could someone enlighten me please? What is DoP?
In South Africa dop is a collective Afrikaans slang word for alcoholic beverages and is also a slang verb for drinking those so I can relate to that but somehow suspect we are not talking about the same thing. Although one need not only drink coffee whilst waiting for the make command to complete. Running the make command on multiple cores seriously cuts into that time though so you need to drink quickly or run it on an older RPI.
DSD over PCM: a way of smuggling DSD data in a PCM stream to a compatible DAC if the output chain doesn't support native DSD. What is DoP (DSD over PCM)? | dCS
Now I want some coffee, thanks
Richard
Yes..I only meant that is possible/got it here to work..it was not a "request" or something..and i do not know if they made a device driver, these "es-sabre-libs" are not "open" as far as what i´ve heard/read..
but anyway, absolute nice, so many thx again !!
Attachments
Last edited:
DSD over PCM: a way of smuggling DSD data in a PCM stream to a compatible DAC if the output chain doesn't support native DSD. What is DoP (DSD over PCM)? | dCS
Now I want some coffee, thanks
Richard
Thanks Richard! In South Africa we also have something called Police Coffee. (Brandy and Coke). If you were close I would offer you any coffee of your choice!!
Last edited:
Advanced ESS Sabre DACs require proprietary drivers to work in software mode.
Only in software mode advanced features of these DACs can be addressed.
Each of these DACs requires a separate MCU (micro computer) on board that controls the DAC chip in SW mode.
Only running it this way manufacturers are able to comply to the very strict ESS licensing rules.
The proprietary Linux audio driver is required to handle that manufacturer specific MCU implementation.
Manufacturers have to put much more effort into getting the OS-driver/MCU programming working.
And then the next challenge for them will be to get that driver handed over and ""accepted"" by the RPI kernel maintainers.
Once this is done, the driver maintenance period starts. Another challenge and cost factor!
E.g. Audiophonics offers a ES9028 HAT DAC that's compliant to ESS terms
according to Audiophonics.
However. The related proprietary driver of Audiophonics is not part of the official kernel. A DAC like that is pretty useless.
If you don't make the driver available in a proper way, not very many people will be able to use it.
E.g. Allo will rather soon offer a SABRE ES9038 based HAT. From Allo we know that they realized that handling the kernel-driver process is key to success.
Meanwhile they have a rather well established process up'n running
to get their drivers accepted by the RPI kernel maintainers.
But. It wasn't easy for them either. It took them quite a while to get there.
And it required quite a patient user and maintainer crowd to hold on to them.
I keep the fingers crossed all the "learnings" from the past, made it into the the upcoming product driver and its handling.
If some of these manufacturers are lucky they may find distros like Moode, which would (or better - used to) offer advanced audio kernels and are committed
to introduce a proprietary driver - which means quite some extra work and rather no benefit for the distro maintainers.
Bottom line. All of you who are interested in such an animal. Before buying, ask if a working driver is available.
And also ask for the places where it's already been successfully implemented.
Don't let you fool by "it will be available soon" or "we're working on it" or "right now it's working in HW mode only".
In these cases better stay away from it or wait until they've done their homework..
Good luck.
Only in software mode advanced features of these DACs can be addressed.
Each of these DACs requires a separate MCU (micro computer) on board that controls the DAC chip in SW mode.
Only running it this way manufacturers are able to comply to the very strict ESS licensing rules.
The proprietary Linux audio driver is required to handle that manufacturer specific MCU implementation.
Manufacturers have to put much more effort into getting the OS-driver/MCU programming working.
And then the next challenge for them will be to get that driver handed over and ""accepted"" by the RPI kernel maintainers.
Once this is done, the driver maintenance period starts. Another challenge and cost factor!
E.g. Audiophonics offers a ES9028 HAT DAC that's compliant to ESS terms
according to Audiophonics.
However. The related proprietary driver of Audiophonics is not part of the official kernel. A DAC like that is pretty useless.
If you don't make the driver available in a proper way, not very many people will be able to use it.
E.g. Allo will rather soon offer a SABRE ES9038 based HAT. From Allo we know that they realized that handling the kernel-driver process is key to success.
Meanwhile they have a rather well established process up'n running
to get their drivers accepted by the RPI kernel maintainers.
But. It wasn't easy for them either. It took them quite a while to get there.
And it required quite a patient user and maintainer crowd to hold on to them.
I keep the fingers crossed all the "learnings" from the past, made it into the the upcoming product driver and its handling.
If some of these manufacturers are lucky they may find distros like Moode, which would (or better - used to) offer advanced audio kernels and are committed
to introduce a proprietary driver - which means quite some extra work and rather no benefit for the distro maintainers.
Bottom line. All of you who are interested in such an animal. Before buying, ask if a working driver is available.
And also ask for the places where it's already been successfully implemented.
Don't let you fool by "it will be available soon" or "we're working on it" or "right now it's working in HW mode only".
In these cases better stay away from it or wait until they've done their homework..
Good luck.
Last edited:
Sudo rm -rf /
Did a whole Solaris server like that once...
I was tres popular...
With Sol10 then disallowed it, so I mustn’t have been the only one
Last edited:
You can stop it by deselecting ‘Automatically parse links in text’ in the edit window