moOde 6.4.0 bug reports

[weaver]

Apparently its a bug in kernels < 4.19.84.
https://github.com/raspberrypi/linux/issues/3331
https://github.com/Hexxeh/rpi-firmware/commits/master

Upcoming final 6.4.1 update will remain on kernel 4.19.83

To update to a newer kernel I use the commands below. You need to specify the kernel's Git commit hash.

Code:

echo "y" | sudo PRUNE_MODULES=1 rpi-update GIT_COMMIT_HASH

After the kernel update completes but before rebooting, clean things up.

Code:

sudo rm -rf /lib/modules.bak
sudo rm -rf /boot.bak
sudo apt-get clean

sudo reboot

You can find the commit hash in the list at the link below.
https://github.com/Hexxeh/rpi-firmware/commits/master

Scroll down to the desired "Bump to kernel ..." line and click on the 7 digit short hash on the right. The long hash which will be used in the rpi-update command will be listed on the right of the page.

For example  "commit 16ce6121464d53a9eb9cf68afbdba7ada8ec7bcd" is for kernel 4.19.84.

Code:

echo "y" | sudo PRUNE_MODULES=1 rpi-update 16ce6121464d53a9eb9cf68afbdba7ada8ec7bcd

Just keep in mind that if you change from the kernel a moOde release ships with and something breaks then I cannot provide any support.

Perfect, thank you.

[TheOldPresbyope]

@weaver

Reading the last few entries in https://github.com/raspberrypi/linux/issues/3331, running "sudo SKIP_KERNEL=1 rpi-update" will NOT update the kernel but WILL update the start*.elf and fixup*.dat files. According to the poster popcornmix this is all you need, and poster BigMuscle85 confirmed it worked.

So, why not try it? At worst, you'll just have to burn a new image if things go wrong.

Here's the output on one of my moOde 6.4.0 players

Code:

pi@moode3a:~ $ sudo SKIP_KERNEL=1 rpi-update
*** Raspberry Pi firmware updater by Hexxeh, enhanced by AndrewS and Dom
*** Performing self-update
*** Relaunching after update
*** Raspberry Pi firmware updater by Hexxeh, enhanced by AndrewS and Dom
#############################################################
WARNING: 'rpi-update' updates to pre-releases of the linux
kernel tree and Videocore firmware.

'rpi-update' should only be used if there is a specific
reason to do so - for example, a request by a Raspberry Pi
engineer.

DO NOT use 'rpi-update' as part of a regular update process.

##############################################################
Would you like to proceed? (y/N)
*** Downloading specific firmware revision (this will take a few minutes)
 % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                Dload  Upload   Total   Spent    Left  Speed
100   168    0   168    0     0   1282      0 --:--:-- --:--:-- --:--:--  1282
100  115M  100  115M    0     0  3959k      0  0:00:29  0:00:29 --:--:-- 5681k
*** Updating firmware
*** As requested, not updating kernel
*** As requested, not updating kernel modules
*** Updating VideoCore libraries
*** Using HardFP libraries
*** Updating SDK
*** Running ldconfig
*** Storing current firmware revision
*** Deleting downloaded files
*** Syncing changes to disk
*** If no errors appeared, your firmware was successfully updated to 57d3b3ac6e893c8545b830a866091cdf8daf4961
*** A reboot is needed to activate the new firmware

and upon reboot, the kernel remains

Code:

Kernel 4.19.83-v7+ #1277, Raspbian 10.2, moOde 6.4.0 2019-11-24

I don't have an local display to press into use ATM but I tried setting framebuffer_depth=32 in config.txt and rebooting. Result:

Code:

pi@moode3a:~ $ vcgencmd get_config framebuffer_depth
framebuffer_depth=32

Looks good from here. 

Regards,
Kent

[weaver]

@weaver

Reading the last few entries in https://github.com/raspberrypi/linux/issues/3331, running "sudo SKIP_KERNEL=1 rpi-update" will NOT update the kernel but WILL update the start*.elf and fixup*.dat files. According to the poster popcornmix this is all you need, and poster BigMuscle85 confirmed it worked.

So, why not try it? At worst, you'll just have to burn a new image if things go wrong.

Here's the output on one of my moOde 6.4.0 players

Code:

pi@moode3a:~ $ sudo SKIP_KERNEL=1 rpi-update
*** Raspberry Pi firmware updater by Hexxeh, enhanced by AndrewS and Dom
*** Performing self-update
*** Relaunching after update
*** Raspberry Pi firmware updater by Hexxeh, enhanced by AndrewS and Dom
#############################################################
WARNING: 'rpi-update' updates to pre-releases of the linux
kernel tree and Videocore firmware.

'rpi-update' should only be used if there is a specific
reason to do so - for example, a request by a Raspberry Pi
engineer.

DO NOT use 'rpi-update' as part of a regular update process.

##############################################################
Would you like to proceed? (y/N)
*** Downloading specific firmware revision (this will take a few minutes)
 % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                Dload  Upload   Total   Spent    Left  Speed
100   168    0   168    0     0   1282      0 --:--:-- --:--:-- --:--:--  1282
100  115M  100  115M    0     0  3959k      0  0:00:29  0:00:29 --:--:-- 5681k
*** Updating firmware
*** As requested, not updating kernel
*** As requested, not updating kernel modules
*** Updating VideoCore libraries
*** Using HardFP libraries
*** Updating SDK
*** Running ldconfig
*** Storing current firmware revision
*** Deleting downloaded files
*** Syncing changes to disk
*** If no errors appeared, your firmware was successfully updated to 57d3b3ac6e893c8545b830a866091cdf8daf4961
*** A reboot is needed to activate the new firmware

and upon reboot, the kernel remains

Code:

Kernel 4.19.83-v7+ #1277, Raspbian 10.2, moOde 6.4.0 2019-11-24

I don't have an local display to press into use ATM but I tried setting framebuffer_depth=32 in config.txt and rebooting. Result:

Code:

pi@moode3a:~ $ vcgencmd get_config framebuffer_depth
framebuffer_depth=32

Looks good from here. 

Regards,
Kent

Many thanks Kent, will give it a go later.

[weaver]

@weaver

Reading the last few entries in https://github.com/raspberrypi/linux/issues/3331, running "sudo SKIP_KERNEL=1 rpi-update" will NOT update the kernel but WILL update the start*.elf and fixup*.dat files. According to the poster popcornmix this is all you need, and poster BigMuscle85 confirmed it worked.

So, why not try it? At worst, you'll just have to burn a new image if things go wrong.

Here's the output on one of my moOde 6.4.0 players

Code:

pi@moode3a:~ $ sudo SKIP_KERNEL=1 rpi-update
*** Raspberry Pi firmware updater by Hexxeh, enhanced by AndrewS and Dom
*** Performing self-update
*** Relaunching after update
*** Raspberry Pi firmware updater by Hexxeh, enhanced by AndrewS and Dom
#############################################################
WARNING: 'rpi-update' updates to pre-releases of the linux
kernel tree and Videocore firmware.

'rpi-update' should only be used if there is a specific
reason to do so - for example, a request by a Raspberry Pi
engineer.

DO NOT use 'rpi-update' as part of a regular update process.

##############################################################
Would you like to proceed? (y/N)
*** Downloading specific firmware revision (this will take a few minutes)
 % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                Dload  Upload   Total   Spent    Left  Speed
100   168    0   168    0     0   1282      0 --:--:-- --:--:-- --:--:--  1282
100  115M  100  115M    0     0  3959k      0  0:00:29  0:00:29 --:--:-- 5681k
*** Updating firmware
*** As requested, not updating kernel
*** As requested, not updating kernel modules
*** Updating VideoCore libraries
*** Using HardFP libraries
*** Updating SDK
*** Running ldconfig
*** Storing current firmware revision
*** Deleting downloaded files
*** Syncing changes to disk
*** If no errors appeared, your firmware was successfully updated to 57d3b3ac6e893c8545b830a866091cdf8daf4961
*** A reboot is needed to activate the new firmware

and upon reboot, the kernel remains

Code:

Kernel 4.19.83-v7+ #1277, Raspbian 10.2, moOde 6.4.0 2019-11-24

I don't have an local display to press into use ATM but I tried setting framebuffer_depth=32 in config.txt and rebooting. Result:

Code:

pi@moode3a:~ $ vcgencmd get_config framebuffer_depth
framebuffer_depth=32

Looks good from here. 

Regards,
Kent

Works here too, frame buffer now sets at 32, kernel version unchanged, JRiver displaying correctly. Thank you.

[feh123]

Try the commands below while playing a Spotify track.

Code:

# Show whether librespot has crashed (it will print a number of its running)
pgrep librespot

# Show ALSA volume level (It should be 100%)
alsamixer

# Show what's being sent to the audio device
cat /proc/asound/card0/pcm0p/sub0/hw_params

Hi

Okay - sorry for the slow response, I am away. I will try these commands as soon as I can. Thanks!

[feh123]

Hi

pgrep librespot returns 987.
alsamixer returns s/PDIF RX as sources for hifiberry digi card. I cannot see 100% mentioned.
hw_params returns
RW_INTERLEAVED
S16_LE
STD
2
44100
225
22050
The moode UI on my browser says spotify is active but no signal is returned by my Naim. If I flip the source to Naim spotify connect it works immediately.

I hope I have followed your instructions correctly and that the above means something! Thanks for your help. Best regards.

[feh123]

Hi

I have hit a new problem. After finishing the above I tried to use Moode and I now get the no sound just using Moode. I tried a reboot and the error appeared - JSON parsing error unexpected end of data line 1 column 1 in the JSON data.

I will try re-installing the softeware tomorrow.

[TookaFace]

In /var/www/command/util.sh

Code:

truncate /var/log/php7.0-fpm.log --size 0

should be:

Code:

truncate /var/log/php7.3-fpm.log --size 0

[feh123]

Hi

Just to follow on re my Spotify issue. I re-installed 6.4.0 and managed to get Moode operational for my NAS based music and internet radio. However Spotify will only work directly through my Naim streamer. Moode Spotify connect is there as an available device on my Spotify app but if I connect to it I get no sound although the app shows no error and I see a timer for the track playing.

[Tim Curtis]

In /var/www/command/util.sh

Code:

truncate /var/log/php7.0-fpm.log --size 0

should be:

Code:

truncate /var/log/php7.3-fpm.log --size 0

Fixed :-)