Upcoming moOde 9.0.0 (Bookworm)

[TheOldPresbyope]

@nullstring there's a reasonably stable ~pre2 package in the repo if you want to try it out.

Code:

1. Boot a Bookworm Lite image
2. sudo apt update && apt list --upgradable
3. sudo apt -y upgrade
4. sudo reboot

5 Install links to Cloudsmith repo
curl -1sLf \
'https://dl.cloudsmith.io/public/moodeaudio/m8y/setup.deb.sh' \
| sudo -E distro=raspbian codename=bookworm bash

6. sudo apt -y install moode-player=9.0.0-1moode1~pre2
7. sudo reboot

After installing the package and rebooting, the system will auto-reboot again after importing the managed config.txt file

Is this the correct steps for installing pre-9.0 on a Pi5?

I suggest you wait for ~pre5, expected this week.

Regards,
Kent

[TheOldPresbyope]

A gentle reminder about these pre-releases of moOde 9.0.0.code.

They are not production releases. They are not even beta releases. They are snapshots of code in active development.

In that regard, this is not a normal user-support thread; it is a tester scrum.

The purpose of testing these pre-releases is to find points of failure and to identify the causes of the failures so they can be fixed. This helps Tim progress.

Don’t install if you expect the code to Just Work™. Do  identify causes to the best of your ability. Do exercise as many different options as possible. Don’t keep identifying the same point of failure.

In the end, moOde 9 is going to be the best yet.

Just my 2-cents worth.

Regards,
Kent

[Patolog1964]

I take it that way too. I'm not an expert in Linux, but if I can, I'll be happy to help with development.

[fralippo]

I've noticed that after updating my library on a HD, several thousands records, I can only see around the first 1000 albums cover. After that they're empty and show a little broken folder symbol on top/left. If I recall correctly that happened with audio formats impossible to reproduce. But they're regularly playing.
Regenerating the album thumbnails cover stops at folder 1014.

Is this behaviour related to the pre-release status? Thank you.

[Tim Curtis]

A gentle reminder about these pre-releases of moOde 9.0.0.code.

They are not production releases. They are not even beta releases. They are snapshots of code in active development.

In that regard, this is not a normal user-support thread; it is a tester scrum.

The purpose of testing these pre-releases is to find points of failure and to identify the causes of the failures so they can be fixed. This helps Tim progress.

Don’t install if you expect the code to Just Work™. Do  identify causes to the best of your ability. Do exercise as many different options as possible. Don’t keep identifying the same point of failure.

In the end, moOde 9 is going to be the best yet.

Just my 2-cents worth.

Regards,
Kent

For sure.

To do the port to Bookworm the right way and take advantage of its new networking, audio and video features requires the corresponding sections of moode code to be re-done. This is a substantial, months long effort and involves a huge amount  of testing on multiple Raspberry Pi's.

I figured the best way to grind through this port is to do regular pre-release code drops and get help in testing from our nice community of users. Thanks to the highly automated, fantastic build tooling created by @bitlab, the moode-player package and image can be created quickly and easily :-)

It looks like we have settled into a weekly code drop schedule, prolly every Thursday or Friday. 

So far audio is beginning to stabilize (there are still some volume and other issues), all the renderers seem to work and networking seems solid except for the lack of support for static IP addressing. DSP has not been addressed yet.

The upcoming ~pre5 drop should get audio pretty close and will include static ip addressing, local display for Pi-3 and some work on DSP. There is also some sort of crash being reported for the System Config screen which I'll try to investigate. 

** One outstanding issue is the current alsa_cdsp plugin does not work on Bookworm/kernel 6.6. There is a test compiled version in the ~pre's that works on Pi-5 only but prolly not 100%. This is being investigated but help is needed so if you are a CamillaDSP fan, an experienced c coder and know the ALSA API (or want to know it) then let us know and I'll provide all the relevant info.

-Tim

[TheOldPresbyope]

@Tim Curtis 

Regarding the vanishing system config page

I was idly jumping among the various config pages (~pre4 on a Pi 4B) when I suddenly discovered I, too, couldn't access the page generated by sys-config.php. Yes, I had previously disabled the integrated WiFi adapter but I don't recall when in the sequence. The player also has an Ethernet connection.

Sifting through the session variables at /var/local/php/ I find this string (followed by roonbridge...)

Code:

ipaddress|a:1:{i:0;s:8:"10.0.0.4";}

Haven't had time to wander through the relevant new PHP functions, sorry. I wasn't expecting a compound construct. It's obvious to this untrained eye that s:8:"10,0,0,4" is the 8-character string of the DHCP-assigned Ethernet address of the integrated Ethernet adapter on this player. I suppose the zero-length integer is the unassigned WiFi address/adapter/something or other?

ETA - Ah, on the same player with another ~pre4 image and both WiFi and Ethernet adapters enabled and connected to my LAN, I see a more congenial

Code:

ipaddress|s:8:"10.0.0.5";

Hope this helps.

Regards,
Kent

[nosferatu_cat]

Just loaded the latest image on a Pi4 with an Allo Boss 2.  I'm assuming that the Boss 2 fix hasn't been implemented yet.  aplay-l shows the Allo HAT as the default audio device and trying to play a file results in an MPD error:

    "Failed to open "ALSA Default" (alsa); Failed to open ALSA device "_audioout": No such device."    

I also loaded it on a Pi 5 with USB audio out and it has worked well.  Looking forward to the production release.

The "Boss 2 fix" was done way back in kernel 6.1.35. If it's not working in Bookworm (kernel 6.6.20) then something else is wrong with the driver. Given that Allo is no longer maintaining their products its up to someone else to debug and possibly fix the driver.

Thanks.

Fortunately, it works fine in v. 8.3.9.  I guess I'll stick with that version for a while.  I realize that Allo has been derelict in supporting its products.  It's too bad.  The Boss 2 measures very well although you can do equally well or better with USB on a Pi 4 or 5.  There are some external DACs for less than $100 that have noise and distortion well below the threshold of audibility.

Yesterday I discovered that the dtparam for Broadcom audio which has always been set to off needs to be on in Bookworm.  I fixed it in my pi 5 yesterday and just now changed it on the pi 4 with the Allo HAT.  It works.  I applied the firmware patch from github last year on this pi so I guess it still applies.  BTW, I emailed Allo last week about this problem and, surprise, have not received a response.  I'm seriously considering giving up on HATs except for transports.  USB and HDMI work well on the pi 4 and 5.  I like the idea of going with an audio solution that doesn't depend on a third party to maintain it.

[TheOldPresbyope]

...
I'm seriously considering giving up on HATs except for transports.  USB and HDMI work well on the pi 4 and 5.  I like the idea of going with an audio solution that doesn't depend on a third party to maintain it.

Yup, me too. There are some genuine advantages to the HATs that I hate to give up, not just technical but also including the compact packaging of my systems and their somewhat lower overall cost. 

I suppose it's wishful thinking that vendors would keep spending money on driver updates but that's life. Even the well-heeled big guns like Apple, Google, et al., (somethings called the FAANG) are quick to drop support for products which are no longer generating new sales. Caveat emptor.

Regards,
Kent

[Tim Curtis]

@Tim Curtis 

Regarding the vanishing system config page

I was idly jumping among the various config pages (~pre4 on a Pi 4B) when I suddenly discovered I, too, couldn't access the page generated by sys-config.php. Yes, I had previously disabled the integrated WiFi adapter but I don't recall when in the sequence. The player also has an Ethernet connection.

Sifting through the session variables at /var/local/php/ I find this string (followed by roonbridge...)

Code:

ipaddress|a:1:{i:0;s:8:"10.0.0.4";}

Haven't had time to wander through the relevant new PHP functions, sorry. I wasn't expecting a compound construct. It's obvious to this untrained eye that s:8:"10,0,0,4" is the 8-character string of the DHCP-assigned Ethernet address of the integrated Ethernet adapter on this player. I suppose the zero-length integer is the unassigned WiFi address/adapter/something or other?

ETA - Ah, on the same player with another ~pre4 image and both WiFi and Ethernet adapters enabled and connected to my LAN, I see a more congenial

Code:

ipaddress|s:8:"10.0.0.5";

Hope this helps.

Regards,
Kent

I haven't gotten to this one yet but thankfully you looked at the raw session file which shows the var type s(tring), a(rray) etc. It confirms what @popeye65 reported in this post https://moodeaudio.org/forum/showthread....6#pid53756 regarding a type mismatch crash.

Must be due to that QA guy again ;-)

[TheOldPresbyope]

Maybe if you gave that guy some Oreo cookies and a Jolt Cola or two?  

That was the remedy back in the day when I could still write code---usually during the night before a few of us were supposed to orchestrate a live demo in multiple workstations in the presence of the project sponsor. I'll never stop hating CORBA.

Sorry I'm going to miss the initial ~pre5 fun. We're flying to the West Coast for a grandchild's first birthday over the weekend.

Regards,
Kent