Moode Audio Player for Raspberry Pi

Hi John,

Yes indeed its a regression :-0 and thankfully the cause is known.

I'll have to temporarily remove the download zip and get a new one made and uploaded. It will take several hours.

I'll post an announcement when the updated download zip is available.

-Tim


I could download a zipfile (3.8.4), but when I used it for my RPI I couldn't boot it anymore.

Now I don't know if this because of a corrupted image file or something else.

I will wait for your announcement for the new zip file...
 
Hi,

A regression was discovered in the r384.zip download. The regression caused MPD 0.20.9 to be included in the build instead of 0.20.10. Note that In-place updates are not affected.

A new r384a.zip is available for download. Don't forget to refresh your Web Browser to get the updated moodeaudio.org download section. Verify the new MD5 hash to ensure the integrity of the download :)

MD5 (moode-sdimg-r384a.zip) = 1ecfe44552f841f2f1b55c9cabadc821

-Tim
 

Attachments

  • moode-r384.png
    moode-r384.png
    207.6 KB · Views: 404
Hi, Bryce.

My days of writing serious Python code are behind me and it's possible there is a trivial fix to your problem which I've forgotten.

That said, I'd think the "proper" way to deal with this is to redesign your program so it is an event-handling service rather than a script which is called repeatedly.

I won't say more lest I misinform with facts I think I remember which aren't so. There's lots of tutorial material out there on the Interweb (TM). If I get a moment, I'll look through some of it myself.

Regards,
Kent

Hi Kent,

If one can read all the 930 pages of this thread, he will find an answer to almost anything, especially when it comes to things like adding LCD, OLED, IR remote and others. The problem is that the information is difficult to find because it is scattered among those 930 pages. Some time when one answer to a question he does not make reference to the original question making the information impossible to find using the search function.
Since moode audio does not have its own forum, i propose that (if it does not violate the rules) people write tutorials as new threads under "PC based", starting every time with the words "Moode audio DIY Tutorials", followed by the object of the tutorial. We may have for example the followings threads:
Moode Audio Player DIY Tutorials: 16x2 LCD display
Moode Audio Player DIY Tutorials: 20x2 OLED display
Moode Audio Player DIY Tutorials: IR remote control
and so on

The DIY part is there to say it is not officially supported by the moode audio people, and people do it on their own risk.
Of course people like Tim, yourself and many others who have expertise on these things would go there from time to time to see if they can be of any "unofficial" help.
I have received help from people here and i am ready to write a few tutorials so that it helps other people and you don't have to answer the same question over and over.
That's what i think, but i am sure the matter have already been discussed here, may be the forum rules don't allow that.

Remy
 
Hi Remy,

The topic of documentation and tutorials has come up before. IMO having a dedicated forum for moOde with thousands of threads would be just as difficult to search as a single thread with thousands pf posts, plus hosting and moderating a forum would create a significant support vector for me.

The other challenge is that detailed documentation and tutorials become stale and inaccurate unless they are maintained and updated as the code and OS change from release to release. This is a very time consuming effort.

Btw, its not that developing and maintaining good documentation and tutorials isn't important, its just that it competes for time to develop, maintain and support moOde itself. Thats the tradeoff I'm faced with and I think the right choice is to devote most of my time to coding and support :)

I'd be willing to consider hosting a section at moodeaudio.org that contains tutorials and documentation. The files could simply be emailed to me and then I'll upload them. The only requirements would be that the submitter (a) specify which version(s) of moOde the document covers and (b) includes an email address or diyAudio userid so that others could contact them for questions.

What do you think?

-Tim
 
Hi,

A regression was discovered in the r384.zip download. The regression caused MPD 0.20.9 to be included in the build instead of 0.20.10. Note that In-place updates are not affected.

A new r384a.zip is available for download. Don't forget to refresh your Web Browser to get the updated moodeaudio.org download section. Verify the new MD5 hash to ensure the integrity of the download :)

MD5 (moode-sdimg-r384a.zip) = 1ecfe44552f841f2f1b55c9cabadc821

-Tim


Enjoying music again, thumbs up for the developer :cheers:
 
Hi, Bryce.

My days of writing serious Python code are behind me and it's possible there is a trivial fix to your problem which I've forgotten.

That said, I'd think the "proper" way to deal with this is to redesign your program so it is an event-handling service rather than a script which is called repeatedly.

I won't say more lest I misinform with facts I think I remember which aren't so. There's lots of tutorial material out there on the Interweb (TM). If I get a moment, I'll look through some of it myself.

Regards,
Kent

Hi Kent,

I think you have it right. Repeatedly calling the script is fine if the script is simple, but event handling would work better and in this case we have an event to work with.

Cheers, Bryce.
 
Hi Bryce,

The symptom you described whereby clicking next track doesn't result in the LCD text changing suggests that there might be blocking happening. One way to troubleshoot is to watch the currentsong.txt file in an ssh terminal in real time using the command below.

watch -n1 cat /var/local/www/currentsong.txt

if the file contents change shortly after pressing Next then the issue can be isolated to either the LCD updater event loop or the Python script. In this case just add some debug code to your script that provides an external indicator that it was actually executed by the LCD update engine. For example write out a file with a time stamp.

-Tim
 
Hi Remy,

The topic of documentation and tutorials has come up before. IMO having a dedicated forum for moOde with thousands of threads would be just as difficult to search as a single thread with thousands pf posts, plus hosting and moderating a forum would create a significant support vector for me.

The other challenge is that detailed documentation and tutorials become stale and inaccurate unless they are maintained and updated as the code and OS change from release to release. This is a very time consuming effort.

Btw, its not that developing and maintaining good documentation and tutorials isn't important, its just that it competes for time to develop, maintain and support moOde itself. Thats the tradeoff I'm faced with and I think the right choice is to devote most of my time to coding and support :)

I'd be willing to consider hosting a section at moodeaudio.org that contains tutorials and documentation. The files could simply be emailed to me and then I'll upload them. The only requirements would be that the submitter (a) specify which version(s) of moOde the document covers and (b) includes an email address or diyAudio userid so that others could contact them for questions.

What do you think?

-Tim

From my perspective, everything Tim says is spot on. I've worked on a number of open-source projects and no matter how well-intentioned we were, our documentation became disorganized over time, not to mention stale. I helped set up, write material for, and moderate several sites. It's exhausting.

I think having a good search ability is an essential. Somehow the diyaudio search capability and I don't seem to get along.

I like the idea of Tim hosting FAQs and tutorials on moodeaudio.org because it gives us focus and identity. If it's open to the major search engine crawlers, then search is effectively free. Just know that whatever we do won't be perfect. And we have to avoid making more work for Tim!

Regards,
Kent
 
Hi Bryce,

The symptom you described whereby clicking next track doesn't result in the LCD text changing suggests that there might be blocking happening. One way to troubleshoot is to watch the currentsong.txt file in an ssh terminal in real time using the command below.

watch -n1 cat /var/local/www/currentsong.txt

if the file contents change shortly after pressing Next then the issue can be isolated to either the LCD updater event loop or the Python script. In this case just add some debug code to your script that provides an external indicator that it was actually executed by the LCD update engine. For example write out a file with a time stamp.

-Tim

Hi Tim,

I am now checking the currentsong.txt file for changes (timestamp) more often. If the file changed while I was scrolling long artist, song or album names I would miss the change sometimes.

Cheers, Bryce.
 
Hi Bryce,

The Py script should not need to check if currentsong.txt has been updated. It the script has a polling loop that does this it will interfere with LCD update engine. All the script needs to do is:

1) parse currentsong.txt
2) update LCD screen

LCD update engine provides the event loop that posts an inotifywait event catcher on the currentsong.txt file. Thus whenever the file changes the LCD update engine runs the Python script.

The Python script will always see an updated currentsong.txt file.

If you like, email me your script and I'll take a look.

-Tim
 
Hi Bryce,

The Py script should not need to check if currentsong.txt has been updated. It the script has a polling loop that does this it will interfere with LCD update engine. All the script needs to do is:

1) parse currentsong.txt
2) update LCD screen

LCD update engine provides the event loop that posts an inotifywait event catcher on the currentsong.txt file. Thus whenever the file changes the LCD update engine runs the Python script.

The Python script will always see an updated currentsong.txt file.

If you like, email me your script and I'll take a look.

-Tim
Only if you promise not to laugh too hard :)
 
Only if you promise not to laugh too hard :)

Hi Bryce,

I see that the Python script needs to perform the text scroll. I thought the LCD firmware did this asynchronously after initializing some sort of scroll bit.

I'm not exactly sure what happens when the LCD update engine runs the script again while its still tied up in one of the scrolling loops.

In any case, since the script itself has to do the text scroll loops the only way it can work with LCD update engine is if the the text scroll loops happen asynchronously via separate threads or via a separate text-scroll-daemon that the main Python script sends text to via a pipe or socket.

Another option is to not use LCD update engine and instead run a polling loop in the Python script.

Btw, in your script you can get play/pause by parsing out 'state' from currentsong.txt file.

-Tim
 
Last edited:
There was an earlier post I made about marking favourite radio stations. The way I have done this is to play the station then make it an individual playlist. A classical station I like, Audiophile Radio, I made a play list called "Audiophile Radio - Classical. Fortunately for me I only need a few fav. stations.

In Rune and Vol. I wasn't able to use the microSD boot card for storage. But with Moode you can and I've tested it. My thought is to now get a 128GB microSD card with Moode image and create a music folder on it for about 120GB of storage. I take my Pi to others places to demo to them the Pi server and listen to music. This way I don't need to take a drive or USB stick. Just have the files I want to p,an on the boot card. Just makes it look smarter and even more compact.
 
Last edited: