Official moOde 6.5.0 support thread

[Tim Curtis]

Hi -enjoying exploring 6.5.   I'm using an RPi 0W -- under the Renderers config section, there's nothing for Spotify anymore - is this no longer an option with the 0W ?

I wasn't able to successfully compile librespot for arm6 (Pi-zero, Pi-1, etc). It can be cross-compiled but I would need someone to volunteer to do this in an ongoing fashion or provide me with a recipe that can be run directly on an arm7  Pi.

There is a workaround that involves replacing the v0.1.1 librespot binary which is arm7-only with the previous binary used in 642 which will run on both arm6 and arm7.

Try this. Then reboot.

Code:

wget -q http://moodeaudio.org/test/librespot-51a634d-armv6l.zip
unzip ./librespot-51a634d-armv6l.zip
sudo rm ./librespot-51a634d-armv6l.zip
sudo chmod +x ./librespot-51a634d-armv6l
sudo mv /usr/local/bin/librespot ./librespot-v0.1.1
sudo cp ./librespot-51a634d-armv6l /usr/local/bin/librespot

-Tim

[swizzle]

Second, the not-so-good-news: Now the option so update the thumbnail cache is gone. I can only regenerate? Why?

The thumbnail cache now updates automatically when you update the mpd library.

Introducing the "adaptive UI" with the playlist "rising up" from the reduced version at the bottom has been difficult to digest, because it increases the number of steps to go from playlist to file browser or library browser from one to two: first collapse the view, then choose the type of library view. This was bad and until 6.4 I found it painful.

The file browser is a library view and how often do you actually switch between them? Most people stick to one (with the exception of maybe the radio browser). Moode since 6.x remembers where you last left off so you can toggle between the full screen playback and the library view you use with one click without wasting space on a navbar a la moode 3.x. 

Now there is no visual cue. I have to guess that clicking on the cover art will lead me to library view – this absolutely makes not sense, it is not intuitive

There was some debate about this but this is the kind of thing you learn once and then you know it. It’s like the little text on your side mirrors about objects being closer than they appear, useful the first time but forever after just in the way.

AND, to add more lack of intuitiveness, one must choose the view from a button.

It’s a menu actually.

The approach that was there in 3.x (4.x as well IIRC) was: there is a series of "tabs" and one chooses the right one. File browser / library browser / cover view / playlist. Like it is now for the configuration mode. This is the right way to do it.

It may be the right way for you, but this isn’t moodenigo 6.5.

As Tim said the move to the menu was needed because 1) screen space is precious and there isn’t enough room to do it like before if we add any new views ), 2) this lets us declutter the ui by moving some things to the menu (e.g. recently added).

At the moment I am sticking with moOde only because I do not have to pay for an equaliser (and the parametric one should really have more than 4 bands, since this makes the use with, say, REW, impossible).

Moode is a passion project for Tim and we’re lucky that he’s demented enough to put as much time into it as he does, but reminding him that the only reason you use it is because you don’t have to contribute anything back to the project probably isn’t the right way to win him over with regard to any requests you may have.

Please reconsider very seriously the insertion of a navigation bar, and restore the ability to go to a "large cover" view of the playlist by clicking on the cover art.

We got rid of the navigation bar on purpose. Most modern music software (e.g. Spotify, Tidal, Roon, etc.) has adopted a similar interface design language and that makes interoperability easier. You’d have to explain what a “large cover” view of the playlist is. 

UX is not about changing the UI to make it "cleaner" and new fonts. It is about the actual useability of the UI.

The only font difference is the use of monospace in the dials now iirc. A less cluttered UI is inherently easier to use though it isn’t necessarily easier to do what you want if you get the distinction. You could say moode lacks discoverability in some areas and I’d agree with you but any software has a learning curve and after the first time insisting on having a separate button to press instead of using the much larger cover seems pedantic. 

(also configuration should NOT need an extra click either, you just go to the last used higher level pane, without the intermediate selection of Audio/Library/Network/System).

The problem with that are the quick link buttons to e.g. mpd configuration or eq settings. While I personally don’t use them and have contemplated removing the dialog as well but ultimately this isn’t swizzle 6.5 either.

As an aside: elements overlaying the album cover on the playbar was a mobile only thing at first because there I wanted to improve the spacing of the playbar and make the text bigger and there isn’t enough room otherwise (so this is unlikely to change there unless we just get rid of the cover) but it migrated to the larger screen version (and the controls flip-flopped) because around the same time Tim got into Amazon HD and liked how the setup worked there (though iirc they use hover to show the controls which we can’t really do because of touch devices).

[Tim Curtis]

I think there is something wrong with formatting of Track Info.

I'm able to repro.

It works fine from Tag or Album view but not from Folder view. I'll add to the bug list :-)

[Tim Curtis]

Btw,

I've fixed some layout issues with the search reset "x" buttons for Library and Playback panels. These fixes will be included in an in-place bug fix update sometime next week :-)

[ElmhurstFun]

Hi -enjoying exploring 6.5.   I'm using an RPi 0W -- under the Renderers config section, there's nothing for Spotify anymore - is this no longer an option with the 0W ?

I wasn't able to successfully compile librespot for arm6 (Pi-zero, Pi-1, etc). It can be cross-compiled but I would need someone to volunteer to do this in an ongoing fashion or provide me with a recipe that can be run directly on an arm7  Pi.

There is a workaround that involves replacing the v0.1.1 librespot binary which is arm7-only with the previous binary used in 642 which will run on both arm6 and arm7.

Try this. Then reboot.

Code:

wget -q http://moodeaudio.org/test/librespot-51a634d-armv6l.zip
unzip ./librespot-51a634d-armv6l.zip
sudo rm ./librespot-51a634d-armv6l.zip
sudo chmod +x ./librespot-51a634d-armv6l
sudo mv /usr/local/bin/librespot ./librespot-v0.1.1
sudo cp ./librespot-51a634d-armv6l /usr/local/bin/librespot

-Tim

Thanks Tim - that worked !!

[Dradder]

Downloaded, installed, got running -- doesn't work for me. When I try to regenerate database of my attached USB drives, it runs for a while, then throws a "MPD Error" message and quits. I realize there's been some mention that Moode isn't really designed for use with large music collections, but my 6.2.0 installation works perfectly with mine; granted, it does take a while to index all the files, but it does do it eventually, with no hangups or stalls. None of the Moode upgrades since 6.2.0 work correctly in this regard, so I'll just keep running 6.2.0, since I really do love this program, and I appreciate all your hard work on it. Thanks!

Prolly a bug in MPD.

Post the error message(s) from MPD log and I'll b happy to investigate.

Here's a screen shot of the error message that pops up when the progress spinner stops, and Moode 6.5.0 stops regenerating the database of my external USB drives:

Attachment

That error message suggests that MPD may have crashed during DB update.

To begin troubleshooting:

1. Reboot
2. Open an SSH terminal
3. tail -f /var/log/mpd/log
4. Menu, Configure, Library, Regenerate MPD database
NOTE: Stay on the Library screen until spinner clears

Check status of MPD
1. pgrep mpd
This will return a number of MPD is running. If MPD has crashed it returns nothing
2. Note the last song in the MPD log.

I'm curious, how many tracks in the collection?

-Tim

I don't have the exact count of tracks in the collection, but it's quite a few; we're talking over 4 terabytes of files, divided between two external USB drives. But however many there are, the fact is that Moode 6.2.0 databases them just fine, and the subsequent versions, including the latest Moode 6.5.0, all throw the same MPD error when asked to do so. So it strikes me that the number of tracks really isn't the issue; the issue is whatever happened to MPD between Moode 6.2.0 and 6.3.0. Sorry I can't be of more help in determining what that difference is; I really like Moode, I use it every day, and I appreciate all your hard work on it.

[swizzle]

@Dradder

I did notice mpd got much pickier about stray non-music files in the music directory, probably in the time frame you’re talking about (in my case there were some zip files).

There’s a post somewhere here about using an .mpdignore (something like that) that you can put in the top level of your music folder (or drive if you don’t use a separate music folder) to keep mpd from trying to scan different file types, see:

https://www.musicpd.org/doc/html/user.ht...e-database

I ended up just removing the files that were throwing a spanner in the works.

[Dradder]

@Dradder

I did notice mpd got much pickier about stray non-music files in the music directory, probably in the time frame you’re talking about (in my case there were some zip files).

There’s a post somewhere here about using an .mpdignore (something like that) that you can put in the top level of your music folder (or drive if you don’t use a separate music folder) to keep mpd from trying to scan different file types, see:

https://www.musicpd.org/doc/html/user.ht...e-database

I ended up just removing the files that were throwing a spanner in the works.

Okay -- but if those files are throwing a spanner in the works with the MPD in Moode 6.5.0 (and the other versions subsequent to 6.2.0), then why aren't they throwing the same spanner into the works with the MPD in Moode 6.2.0, with the exact same files on my external USB drives, all of which are being correctly databased by Moode 6.2.0? And just for the record, there are no zip files on my USB drives -- I'm pretty thorough about grooming those.

Thanks for your help, but I just don't think this is the issue here.

[swizzle]

@Dradder

I did notice mpd got much pickier about stray non-music files in the music directory, probably in the time frame you’re talking about (in my case there were some zip files).

There’s a post somewhere here about using an .mpdignore (something like that) that you can put in the top level of your music folder (or drive if you don’t use a separate music folder) to keep mpd from trying to scan different file types, see:

https://www.musicpd.org/doc/html/user.ht...e-database

I ended up just removing the files that were throwing a spanner in the works.

Okay -- but if those files are throwing a spanner in the works with the MPD in Moode 6.5.0 (and the other versions subsequent to 6.2.0), then why aren't they throwing the same spanner into the works with the MPD in Moode 6.2.0, with the exact same files on my external USB drives, all of which are being correctly databased by Moode 6.2.0? And just for the record, there are no zip files on my USB drives -- I'm pretty thorough about grooming those.

Thanks for your help, but I just don't think this is the issue here.

The way mpd works isn't fixed in stone, Max obviously changed how the library scan works between the version that moode 6.2 used and now. And there's literally nothing Tim can do to fix this except link you to a binary of the mpd that moode 6.2 uses if he still has one.

The easiest recourse is to look at the mpd log as Tim suggested to see where it's crashing and remove whatever file(s) it's having a problem with. Alternately you can file a bug against mpd but be warned it's not for the faint of heart.

[Dradder]

@Dradder

I did notice mpd got much pickier about stray non-music files in the music directory, probably in the time frame you’re talking about (in my case there were some zip files).

There’s a post somewhere here about using an .mpdignore (something like that) that you can put in the top level of your music folder (or drive if you don’t use a separate music folder) to keep mpd from trying to scan different file types, see:

https://www.musicpd.org/doc/html/user.ht...e-database

I ended up just removing the files that were throwing a spanner in the works.

Okay -- but if those files are throwing a spanner in the works with the MPD in Moode 6.5.0 (and the other versions subsequent to 6.2.0), then why aren't they throwing the same spanner into the works with the MPD in Moode 6.2.0, with the exact same files on my external USB drives, all of which are being correctly databased by Moode 6.2.0? And just for the record, there are no zip files on my USB drives -- I'm pretty thorough about grooming those.

Thanks for your help, but I just don't think this is the issue here.

The way mpd works isn't fixed in stone, Max obviously changed how the library scan works between the version that moode 6.2 used and now. And there's literally nothing Tim can do to fix this except link you to a binary of the mpd that moode 6.2 uses if he still has one.

The easiest recourse is to look at the mpd log as Tim suggested to see where it's crashing and remove whatever file(s) it's having a problem with. Alternately you can file a bug against mpd but be warned it's not for the faint of heart.

Well, no -- IMO, the easiest recourse is for me to continue using Moode 6.2.0, which works fine for my purposes, as it doesn't incorporate a buggy version of MPD, which causes MPD to crash rather than correctly databasing a large multi-terabyte collection of music files, which previous non-buggy versions of MPD were perfectly capable of doing. If the MPD folks want to put out demonstrably buggy versions of their program, that's their business, but I'm under no obligation to use other programs (such as post-6.2.0 versions of Moode) that incorporate those buggy MPD versions. 

I'd love to have an updated, latest-&-greatest version of Moode, which doesn't incorporate a buggy version of MPD, as I'm sure there have been some attractive improvements made. But MPD crashing rather than correctly databasing my admittedly large collection of music files, the way previous MPD versions did -- that's pretty much a deal-killer for me. I run Moode on a very high-resolution audio system, and I really don't hear any difference in audio quality between files played with Moode 6.2.0 versus those same files that I'm able to play with Moode 6.5.0. So why shouldn't I stick with Moode 6.2.0? It works! I wouldn't be the first person who continues using an older version of a program -- that works! -- rather than pointlessly trying to migrate to a newer version that doesn't work. And right now, post-6.2.0 versions of Moode, including the latest 6.5.0 version, simply don't work, because of what increasingly appears to be the buggy version of MPD that they incorporate.