Moode Audio Player for Raspberry Pi

After about 8 hours of monkeying around with this new version, I'm over it. I have a day job where I have to figure out really hard stuff and they PAY me to do it. Two SD cards, 3 attempts and two different scripts, and the closest I got to a working version was one that was sluggish as an ox and would not run MPD after I plugged in my USB stick with music on it. Not my idea of fun, or a way to enjoy my music. Sorry, I'm moving on. Tim, I guess you get to keep that contribution, I got something for it, just not as much as I had hoped. Good luck with this, I think you are going to need a working bullet proof script, though...

I don't know why it is so hard to you to make it work but I started from scratch and it only took me 40 minutes with build recipe if we discount the wasted time when I forgot to plugin my Ethernet switch power.
 
After about 8 hours of monkeying around with this new version, I'm over it. I have a day job where I have to figure out really hard stuff and they PAY me to do it. Two SD cards, 3 attempts and two different scripts, and the closest I got to a working version was one that was sluggish as an ox and would not run MPD after I plugged in my USB stick with music on it. Not my idea of fun, or a way to enjoy my music. Sorry, I'm moving on. Tim, I guess you get to keep that contribution, I got something for it, just not as much as I had hoped. Good luck with this, I think you are going to need a working bullet proof script, though...
Sorry to hear that, are you able to put the required Raspian base image on a TF card using Etcher app? Once you do that, apply Heeboo's one-script-rules-all script. It works perfectly for me.
 
I have to say I have LOVED moodeaudio. Up until now. I tried multiple SD cards, Tim's script and then Heebos. The best I ever got after many wasted hours was a terribly slow player that won't recognize my USB stick with all of my music. MPD won't even respond now. I used to like that is was so feature reach. Now I fear it has become to bloated. I can't 'Enjoy the music' if it won't read USB stick. I guess I got about 6 months out of my developer contribution. Its just not worth the hassle.
And no, I'm not some wet-behind the ears noob. I used to program in assmbler. But I don't want to spend days on this, its for fun.

After about 8 hours of monkeying around with this new version, I'm over it. I have a day job where I have to figure out really hard stuff and they PAY me to do it. Two SD cards, 3 attempts and two different scripts, and the closest I got to a working version was one that was sluggish as an ox and would not run MPD after I plugged in my USB stick with music on it. Not my idea of fun, or a way to enjoy my music. Sorry, I'm moving on. Tim, I guess you get to keep that contribution, I got something for it, just not as much as I had hoped. Good luck with this, I think you are going to need a working bullet proof script, though...

Sorry to hear that. I quote some posts which can really help you to success.
Please don’t forget automatic building process need around 40 minutes with at least 8 reboot.

You can monitor this with a cat command as described below, you must wait to have the END output before configuring or using MoOde.

Regards

Just wanted to let everyone know, that after having some problems, I started from scratch and got Moode Audio 4.0, Beta 12, up a running last night on a Raspberry Pi3.

A couple orders of business first.

1.) Thanks Tim for Moode Audio; and,
2.) Thanks again, koda59 for the build script.

I used a Mac, macOS, for interfacing with the Raspberry Pi3, and the building of the image.

For those that are intimidated by 4.0 and the associated necessity of building your own image, I feel your fears are largely unwarranted. Frankly, the build script is but three lines of text that you can copy and paste, directly from the Moode Audio website.

That said, I think where the confusion and/or trouble for most comes in now is in what I'll call general familiarity with computing and the Raspberry Pi. At least, I feel, that was the case for me.

I also think it might be helpful to tell someone, about to engage in an image build of Moode Audio 4.0 what they need in terms of hardware, in advance, if you will. For instance, here's what I used:

- a first microSD card (Generally, this microSD card will have Raspbian Lite on it, be inserted into the micro SD card slot on the Raspberry Pi, and is used to run the Raspberry Pi during the image build process.)

- a microSD card to USB adapter

- a second microSD card (This microSD card is inserted into the microSD card to USB adapter, and is plugged into a USB port on the Raspberry Pi, and is the "target" drive for the image file. Once the image is created or built on this microSD card, it is inserted into the Raspberry Pi, and that is the one you'll run on going forward, listening to music.)

Another thing I think might be helpful to tell a "novice" is that there are really sort of two "phases" to the build each associated with a different microSD card. These, what I just called "phases", referred to as "steps" in the prompting, only the second of which is specifically mentioned - frankly, the script was a bit confusing for me in the prompting here. I'm not sure I use the term "step"...just, a friendly suggestion...to make us all better off...

Here's what I did.

1. On my Mac, I downloaded Raspbian Lite from the Internet, and once downloaded, it unzipped.

2. On my Mac, I downloaded Etcher from the Internet and installed it.

3. Using an adapter that came with the microSD cards, I inserted the microSD card into the SDXC card slot on my Mac. I then used Etcher, to burn the Raspbian Lite image to a first microSD card. Alternatively, you could the aforementioned microSD card to USB adapter and a USB port on your Mac, if your Mac doesn't have a SDXC card slot.

4. I removed and reinserted the adapter containing the microSD to be sure that the card, shown as "boot", appeared on my desktop.

5. On my Mac, I opened Terminal and entered the following command:

echo "" > /Volumes/boot/ssh

FYI: This puts a filed called "ssh", without any extension, on the boot volume so that you can ssh into the Raspberry Pi once this card is installed in the microSD card slot on the Raspberry Pi.

6. I remove the microSD card and inserted it into my Raspberry Pi3, connected the Raspberry Pi3 to my router, and powered it up.

7. On my Mac, I downloaded and installed PI Finder, see: Ivan X's Raspberry Pi Party

8. Run Pi Finder on my Mac - this tells you the IP address of your Raspberry Pi (make note of it) and prompts you, allowing you to login. Alternatively, you can use the IP address, and use Terminal on your Mac to issue the command:

ssh pi@[IP address]

and login.

9. Now that I was logged into the Raspberry Pi, I copied and paste each of the three lines at the bottom of the Moode Audio website in succession, see:

"Enter these commands via SSH on a Raspberry Pi running Raspbian.

1. Download the Image Builder

cd /home/pi
sudo wget -q http://moodeaudio.org/downloads/mos/mosbuild.sh -O /home/pi/mosbuild.sh
sudo chmod +x /home/pi/mosbuild.sh

2. Start the Image Builder

sudo ./mosbuild.sh

following the directions that appeared in Terminal along the way...

10. When prompted, I powered down the Raspberry Pi, remove the first microSd card from the Raspberry Pi and inserted the second microSD card that was in the microSD to USB adapter, and powered the Raspberry Pi back on - the building of the imaging continuing on...the build script refers to this as "step 2".

11. After 30-45 minutes, on my Mac, in Safari, I entered "moode.local" into the browser.

12. As before with Moode Audio 3.8.x, I made the necessary configuration changes in Moode Audio 4.0, beta 12, to run on wireless and to select by DAC...etc.

That's it. Hope this write up helps someone!

Hello everyone,

I hope you had a wonderful holiday spending time with the most important people in your life.

For those just joining the thread -- perhaps Santa brought you a brand new RPi -- I thought I'd quickly summarise the build options for Tim Curtis's moOde audio player:


  1. IMG file: There is no img option at the moment due to GPL licensing issues. Short answer here http://www.diyaudio.com/forums/pc-based/271811-moode-audio-player-raspberry-pi-1218.html#post5282792
  2. Source files + build recipe: this is a step-by-step process that involves building moOde on a Raspberry Pi running the Raspbian OS via SSH terminal commands. You will need two microSD cards, one for running Raspbian and one for building moOde, and a microSD-USB card adapter (multi-card adapters are not recommended as they can appear as multiple mount points and confuse things). This essentially involves copying commands from the build recipe into the terminal and allows a lot of customisation opportunities for experienced Linux users. Source files and recipe can be downloaded at moodeaudio.org
  3. moOde OS Image Builder: this is an automated script by koda59 and Tim that uses the above build recipe that is run on an RPi with Raspbian. As per the build recipe, it requires two SD cards and an adapter. It is (mostly) set and forget but there are some options that need user input at the start and you will be prompted to remove the microSD card from the USB adapter and use it to reboot the RPi to continue the build. Details are in the support section of moodeaudio.org
  4. Moosimbu script: this is a patched version of the automated image builder provided by HeeBoo. It requires only one microSD card and updates the existing Raspbian installation to moOde OS. It is a work in progress and supported by HeeBoo. See this post for downloading the script http://www.diyaudio.com/forums/pc-based/271811-moode-audio-player-raspberry-pi-1216.html#post5281736
  5. DietPi installation: moOde is now installable via the DietPi distribution. Some functionality is not integrated yet but this should be solved in the future: DietPi / Fuzon • View topic - v159
Some tips:

  • I suggest using ethernet to connect the RPi to the network/internet while building as the process seems to run more smoothly than via WiFi. However YMMV.
  • Be patient and allow some time for the build process. Some users have reported more than an hour.
  • You can monitor the build process via SSH during the final stage (the RPi booting from the moOde OS card) with the following command (thanks HeeBoo). The password to login at this stage is moodeaudio:
Code:
 ssh pi@moode "cat ~/mosbuild.log | grep 'COMPONENT\|STEP\| Compile \| END\| Error'"
Emendations or updates are very welcome.


Richard

Hi all,

I have maybe some help regarding "problems during Step 1 of builing moOde 4beta12 image":

Maybe some of you did the same error I did yesterday: I read (very fast) what I have to do, so I plugged of everything from Pi, except keyboard and an USB-cardreader with an empty card for the moOde image (you see the error already?). Any time I tried I stuck there:

** Plug in target USB drive for the new OS
** Is target USB drive plugged in (y/n)? y
** Error: Unable to find USB drive
** Image build cancelled


But my USB-cardreader was shown: /dev/sda1

pi@raspberrypi:~ $ sudo blkid -o list -w /dev/null
device fs_type label
-------------------------------------------------------
/dev/mmcblk0p1 vfat boot
/dev/mmcblk0p2 ext4 rootfs
/dev/sda1 ext4 MOODE1
/dev/mmcblk0


WTF ... hm ... I started checking the code of "mosbuild.sh", I found that the devices are exported two times in files which are compared to find the USB device ... ??? ... how should this work ... ahhhh ... I have to plug in USB cardreader BETWEEN these "two times":

** Unplug all USB storage devices from the Pi
** Are all USB storage devices unplugged (y/n)? y
** Plug in target USB drive for the new OS <<<<<<<<<<< here
** Is the USB drive plugged in (y/n)? y

Clear, my mistake ("read the fu??ing manual"), but I think this VERY IMPORTANT step should be specified more clear like:

** Unplug ALL USB storage devices from the Pi (**including target USB drive for the new OS**)
** Are ALL USB storage devices unplugged (y/n)?

** NOW plug in target USB drive for the new OS
** Is target USB drive plugged in (y/n)?

Hope this helps someone ... maybe also problem of some "multiple cardreader issues" (?)

Best regards
Tom
 
Can someone confirm that Spotify streaming does not work from Android devices? Spotify cannot see moode at all.
Maybe bubbleupnp needs to be used?

I have no problems with iOS where airplay works flawlessly.

You can stream Tidal, GooglePlay and Qobuz via Bubble but not Spotify. To stream Spotify over Moode you would need to install Raspotify, but there are volume issues which have made Tim reluctant to include it.
Best to stick with iOS/Airplay.
 
Hi everybody. I built my own speakers, and now that they’re done I hear that they can use some equalizing. I stream to a Raspberry Pi with a Dion Loco DAC AMP with Airplay and I assumed that I could use Moode to equalize the signal before it goes to the Loco.
But this is not how it works, right? The equalizers don’t seem to have any effect on the Airplay stream.
Do you have any ideas how I can enable this feature? Can it be built in into Moode? Or is there any other way I could achieve this? Any help is very much appreciated.
 
You can stream Tidal, GooglePlay and Qobuz via Bubble but not Spotify. To stream Spotify over Moode you would need to install Raspotify, but there are volume issues which have made Tim reluctant to include it.
Best to stick with iOS/Airplay.

I bought Tidal HiFi subscription now.

Tried BubbleUPnP on my Android device for this - it did not stream anything to MoOde UPnP.
Then I downloaded Tidal app on my iphone and tried using MoOde Airplay. No streaming there as well.
I thought it was a problem due to the HiFi quality, so I selected normal and that did not play either.
Then I restarted MPD and tried.
Still no luck.

MoOde 3.8 here.
 
Where is the new mosbuild ?

Sorry,
But i don't understand why Tim doesn't update the Koda's script to the latest version... It's more accurate than the first version, it's moOde version independent (for the mosbuild.sh part) and it's ready for the actual version (4b12).
Too many are bad installation experiences and don't want anyway redo these. I had made some patches for improve this, Koda take some, but never Tim feedback theses patches, why ? Because I change Koda script without permission ? I just want improve the User Experience.

@Tim, why wait the next "revision" for distrib it ? for the next version mosbuild_worker.sh must be redo (modified?) in all cases.

If it's distributed we can,(maybe with Koda), have feedback and improve this new script without waiting like now.(i'm not waiting)

If you need some help for the installation process maybe i can help us, tell me !

Thanks for all.

Good Next
 
Last edited:
It seems MoOde got stuck on Airplay and never switched to another audio source.
After a restart of MPD and a complete shutdown of RPI and restart Tidal started working via Airplay and also via Bubble Upnp.


I bought Tidal HiFi subscription now.

Tried BubbleUPnP on my Android device for this - it did not stream anything to MoOde UPnP.
Then I downloaded Tidal app on my iphone and tried using MoOde Airplay. No streaming there as well.
I thought it was a problem due to the HiFi quality, so I selected normal and that did not play either.
Then I restarted MPD and tried.
Still no luck.

MoOde 3.8 here.
 
Sorry,
But i don't understand why Tim doesn't update the Koda's script to the latest version... It's more accurate than the first version, it's moOde version independent (for the mosbuild.sh part) and it's ready for the actual version (4b12).
Too many are bad installation experiences and don't want anyway redo these. I had made some patches for improve this, Koda take some, but never Tim feedback theses patches, why ? Because I change Koda script without permission ? I just want improve the User Experience.

@Tim, why wait the next "revision" for distrib it ? for the next version mosbuild_worker.sh must be redo (modified?) in all cases.

If it's distributed we can,(maybe with Koda), have feedback and improve this new script without waiting like now.(i'm not waiting)

If you need some help for the installation process maybe i can help us, tell me !

Thanks for all.

Good Next

Hi @HeeBoo,

Priority is to get newUI and Bluetooth Connect finished. They are almost done! Next on the list is to get the new mosbuild script tested and uploaded :)

In the meantime maybe I'll upload the script as-is and make a "TEST" link for it so people can begin to use it now.

What do you think?

-Tim
 
Sorry,
But i don't understand why Tim doesn't update the Koda's script to the latest version... It's more accurate than the first version, it's moOde version independent (for the mosbuild.sh part) and it's ready for the actual version (4b12).
Too many are bad installation experiences and don't want anyway redo these. I had made some patches for improve this, Koda take some, but never Tim feedback theses patches, why ? Because I change Koda script without permission ? I just want improve the User Experience.

@Tim, why wait the next "revision" for distrib it ? for the next version mosbuild_worker.sh must be redo (modified?) in all cases.

If it's distributed we can,(maybe with Koda), have feedback and improve this new script without waiting like now.(i'm not waiting)

If you need some help for the installation process maybe i can help us, tell me !

Thanks for all.

Good Next

A modest proposal:

Some of you already know that a GitHub account "moode-player" was created about a month ago containing two GitHub repos: moode and mosbuild

See Moode Audio Player * GitHub

AIUI, this was done as a convenience to provide a snapshot of Tim's codebase to the DietPi project (which is based in GitHub). Tim has not been using these moode/mosbuild repos in his daily workflow but that doesn't mean we can't contribute via GitHub:

Post comments to Tim's mosbuild repo, clone the mosbuild repo to your own GitHub or git project, make your revisions, and post pull-requests to Tim's mosbuild repo. That way, your proposals can be tracked, we can discuss them in the GitHub comments, and agreed changes can be merged as appropriate. We'll all be seeing the "latest version" as well as the history of merged and rejected changes.

A parallel proposal is to use the "GitHub Project Page" capability to create a website with expanded installation instructions and possibly even HowTo's on various topics. It can be integrated into the above GitHub site [1]. I've already dabbled with this in a cloned repo and hope in the coming weeks to post a first cut as my own GitHub project, built in such a way that it can be merged into either the moode or the mosbuild repo. As above, the GitHub workflow enables others to comment and propose changes.

To me, full use of GitHub conveys several benefits:
  • organizes proposals for technical changes (in place of the current cacophony of thread posts, emails, and tweets addressed to Tim)
  • clarifies which proposals are accepted and how the changes are made
  • reduces the techie crosstalk on this thread
  • interested parties receive email notifications

I'm sure Tim is overwhelmed with work already and I don't want to add to his burden. IMHO this approach could help spread the work in a controllable way but that's just me based on my experiences in other GitHub-based projects. I'm proposing we start with mosbuild but if we're successful, then maybe moode too?

Full disclosure: Tim and I had several exchanges about git/GitHub when he was creating the GitHub repos. As a courtesy, he added me as an administrator, a power I have not exercised.

Regards,
Kent

[1] It is possible to configure GitHub to serve a Project Page to a custom domain. I haven't tried this capability, but it might be possible to serve the GitHub Project Page via a subdomain of Tim's moodeaudio.org. A lot depends on the DNS manager for his domain.
 
A modest proposal:

Some of you already know that a GitHub account "moode-player" was created about a month ago containing two GitHub repos: moode and mosbuild

See Moode Audio Player * GitHub

AIUI, this was done as a convenience to provide a snapshot of Tim's codebase to the DietPi project (which is based in GitHub). Tim has not been using these moode/mosbuild repos in his daily workflow but that doesn't mean we can't contribute via GitHub:

Post comments to Tim's mosbuild repo, clone the mosbuild repo to your own GitHub or git project, make your revisions, and post pull-requests to Tim's mosbuild repo. That way, your proposals can be tracked, we can discuss them in the GitHub comments, and agreed changes can be merged as appropriate. We'll all be seeing the "latest version" as well as the history of merged and rejected changes.

A parallel proposal is to use the "GitHub Project Page" capability to create a website with expanded installation instructions and possibly even HowTo's on various topics. It can be integrated into the above GitHub site [1]. I've already dabbled with this in a cloned repo and hope in the coming weeks to post a first cut as my own GitHub project, built in such a way that it can be merged into either the moode or the mosbuild repo. As above, the GitHub workflow enables others to comment and propose changes.

To me, full use of GitHub conveys several benefits:
  • organizes proposals for technical changes (in place of the current cacophony of thread posts, emails, and tweets addressed to Tim)
  • clarifies which proposals are accepted and how the changes are made
  • reduces the techie crosstalk on this thread
  • interested parties receive email notifications

I'm sure Tim is overwhelmed with work already and I don't want to add to his burden. IMHO this approach could help spread the work in a controllable way but that's just me based on my experiences in other GitHub-based projects. I'm proposing we start with mosbuild but if we're successful, then maybe moode too?

Full disclosure: Tim and I had several exchanges about git/GitHub when he was creating the GitHub repos. As a courtesy, he added me as an administrator, a power I have not exercised.

Regards,
Kent

[1] It is possible to configure GitHub to serve a Project Page to a custom domain. I haven't tried this capability, but it might be possible to serve the GitHub Project Page via a subdomain of Tim's moodeaudio.org. A lot depends on the DNS manager for his domain.

Hi Kent,

I don't currently use the Git repos for workflow or issue tracking so this definitely is not something I can support. Their only purpose at this time is to contain a snapshot of the releases and nothing more.

-Tim
 
Use your feelings, you must. :D :D :D
But currently, risk of multiple workflow :/

Maybe Tim can release a beta installer ... or maybe we can wait a bit more ;)
A modest proposal:

Some of you already know that a GitHub account "moode-player" was created about a month ago containing two GitHub repos: moode and mosbuild

See Moode Audio Player * GitHub

AIUI, this was done as a convenience to provide a snapshot of Tim's codebase to the DietPi project (which is based in GitHub). Tim has not been using these moode/mosbuild repos in his daily workflow but that doesn't mean we can't contribute via GitHub:

Post comments to Tim's mosbuild repo, clone the mosbuild repo to your own GitHub or git project, make your revisions, and post pull-requests to Tim's mosbuild repo. That way, your proposals can be tracked, we can discuss them in the GitHub comments, and agreed changes can be merged as appropriate. We'll all be seeing the "latest version" as well as the history of merged and rejected changes.

A parallel proposal is to use the "GitHub Project Page" capability to create a website with expanded installation instructions and possibly even HowTo's on various topics. It can be integrated into the above GitHub site [1]. I've already dabbled with this in a cloned repo and hope in the coming weeks to post a first cut as my own GitHub project, built in such a way that it can be merged into either the moode or the mosbuild repo. As above, the GitHub workflow enables others to comment and propose changes.

To me, full use of GitHub conveys several benefits:
  • organizes proposals for technical changes (in place of the current cacophony of thread posts, emails, and tweets addressed to Tim)
  • clarifies which proposals are accepted and how the changes are made
  • reduces the techie crosstalk on this thread
  • interested parties receive email notifications

I'm sure Tim is overwhelmed with work already and I don't want to add to his burden. IMHO this approach could help spread the work in a controllable way but that's just me based on my experiences in other GitHub-based projects. I'm proposing we start with mosbuild but if we're successful, then maybe moode too?

Full disclosure: Tim and I had several exchanges about git/GitHub when he was creating the GitHub repos. As a courtesy, he added me as an administrator, a power I have not exercised.

Regards,
Kent

[1] It is possible to configure GitHub to serve a Project Page to a custom domain. I haven't tried this capability, but it might be possible to serve the GitHub Project Page via a subdomain of Tim's moodeaudio.org. A lot depends on the DNS manager for his domain.
 
Last edited:
Hi @HeeBoo,

Priority is to get newUI and Bluetooth Connect finished. They are almost done! Next on the list is to get the new mosbuild script tested and uploaded :)

In the meantime maybe I'll upload the script as-is and make a "TEST" link for it so people can begin to use it now.

What do you think?

-Tim

A modest proposal:

Some of you already know that a GitHub account "moode-player" was created about a month ago containing two GitHub repos: moode and mosbuild

See Moode Audio Player * GitHub

AIUI, this was done as a convenience to provide a snapshot of Tim's codebase to the DietPi project (which is based in GitHub). Tim has not been using these moode/mosbuild repos in his daily workflow but that doesn't mean we can't contribute via GitHub:

Post comments to Tim's mosbuild repo, clone the mosbuild repo to your own GitHub or git project, make your revisions, and post pull-requests to Tim's mosbuild repo. That way, your proposals can be tracked, we can discuss them in the GitHub comments, and agreed changes can be merged as appropriate. We'll all be seeing the "latest version" as well as the history of merged and rejected changes.

A parallel proposal is to use the "GitHub Project Page" capability to create a website with expanded installation instructions and possibly even HowTo's on various topics. It can be integrated into the above GitHub site [1]. I've already dabbled with this in a cloned repo and hope in the coming weeks to post a first cut as my own GitHub project, built in such a way that it can be merged into either the moode or the mosbuild repo. As above, the GitHub workflow enables others to comment and propose changes.

To me, full use of GitHub conveys several benefits:
  • organizes proposals for technical changes (in place of the current cacophony of thread posts, emails, and tweets addressed to Tim)
  • clarifies which proposals are accepted and how the changes are made
  • reduces the techie crosstalk on this thread
  • interested parties receive email notifications

I'm sure Tim is overwhelmed with work already and I don't want to add to his burden. IMHO this approach could help spread the work in a controllable way but that's just me based on my experiences in other GitHub-based projects. I'm proposing we start with mosbuild but if we're successful, then maybe moode too?

Full disclosure: Tim and I had several exchanges about git/GitHub when he was creating the GitHub repos. As a courtesy, he added me as an administrator, a power I have not exercised.

Regards,
Kent

[1] It is possible to configure GitHub to serve a Project Page to a custom domain. I haven't tried this capability, but it might be possible to serve the GitHub Project Page via a subdomain of Tim's moodeaudio.org. A lot depends on the DNS manager for his domain.

@Tim: I think we must found a solution for upgrade this part without linking to the moOde revisions for the moment.
I don't want my patches in test mode but a way to update (in a short time) the builder part when it's ready. The first revision is for sure buggy and all these are already corrected by Koda. But we can't access to it.
I can put my scripts on a server too for testing but I don't want distribute myself without autorisation any work i do or Koda do for the installation process and i don't think is a good way (multiple adresse server, multiple different versions, etc...)

I love the proposal of theOldPresbyope.
For the moment I haven't GitHub account and I doesn't want "fork" the mosbuild project, but it's a good idea to use the actual GitHub for talk about all of this, make a dev "branch" and open it to all of us for helping and improving the development.
With a dev branch all of us can test and give feedback without replace the original way and give a chance to all who have problem with the original version to test with the dev version and maybe avoid the problem.
This is for me a good way for the 2 repos (mosbuild & moode), this is more simple for keep multiple revision up-to-date.
If I must create a GitHub account for helping the dev of moOde, i will do it !

And I hope we can continue to talk about that there ! for more clarity here and more clarity for the development !

I'm pretty sur Tim work like no others on this project and hope my comment no hurting any of you, this is not the goal. I just want make better this project and helping.

I'm ready for all moves just give me the way.

Regards
 
Hi @HeeBoo,

Priority is to get newUI and Bluetooth Connect finished. They are almost done! Next on the list is to get the new mosbuild script tested and uploaded :)

In the meantime maybe I'll upload the script as-is and make a "TEST" link for it so people can begin to use it now.

What do you think?

-Tim

Hi @Tim, @HeeBoo,

from the perspective of "user experience" I would strongly recommend to make the "one-card-script" available on the MoodeAudio website. Perhaps additionally to the official builder and with a short step-by-step instruction.

All I can comment to the script is: It worked flawlessly for my configuration (Win7 PC with Putty for SSH, RPi3 with official 7" touchscreen, network via ethernet, audio out via HDMI to Harman Kardon AVR). Took about 2 hours from blank SD card to working image. Again: Big thanks to HeeBoo for his modifications and of course the same to Koda59 for the initial script.

@Tim: I never before had a feature request (BT speaker support) positively answered within 2 days. "Our" IT guys usually need 2 weeks only to answer whether the request will be considered... This is awesome, like the entire MoodeAudio project is! Big thanks to you - the pure amount and the speed of your work is impressive.
 
The new script is able to do an automatic build with an USB reader or a direct install.
It fixes every problem meet and report until now and Heeboo contribute to it.

Now Tim have to review some part of it ... so you must be a bit more patient.

Regards

Ok, the better :)

Regarding patience: This is my second name. And I have a working beta12 which is more than fine for me currently... :D