Ok, thanks Tim.
I will reformat the SD card and start from scratch, it only takes a few minutes.
Cheers, Bryce.
Hi,
Nice bit of work
If step 8 could be fully automated I'd be interested in trying to integrate this config into MoOde.
The zoom setting can be made via css. Can "minimal scrollbar" be automated via a config file setting?
-Tim
DO it !!
I also have mine working for a while with Moode 3.6.
I wanted to keep the touchscreen on when playing music, and allow it to turn off (screensaver) when I'm no longer playing. So, I created a .py program to turn the screen on, and pointed the Moode's update screen option into that program. Works great
It actually turns the screen on even just adjusting the volume when playing spotify.Hi
I've just installed moode 3.6 and i tried to install Spotify Connect following the instructions found here : https://github.com/RafaPolit/moode-spotify-connect-web
In the section "Spotify connect web" i don't understand what i have to do. It's written "Replace the [hw:1] in --playback_device with the ALSA device you want to use" but i don't know wich ALSA device i have to select. I did "$ aplay -L" but i don't understand what i get.
I precise that i use hdmi output to my amplifier.
Could you help me on this installation ? Is there maybe an easier tutoirial (for a very non specialist as me) to explain how to install spotify connect on moode audio ?
Thanks for your support.
Bertrand
I've just installed moode 3.6 and i tried to install Spotify Connect following the instructions found here : https://github.com/RafaPolit/moode-spotify-connect-web
In the section "Spotify connect web" i don't understand what i have to do. It's written "Replace the [hw:1] in --playback_device with the ALSA device you want to use" but i don't know wich ALSA device i have to select. I did "$ aplay -L" but i don't understand what i get.
I precise that i use hdmi output to my amplifier.
Could you help me on this installation ? Is there maybe an easier tutoirial (for a very non specialist as me) to explain how to install spotify connect on moode audio ?
Thanks for your support.
Bertrand
So, it is with great sadness that I have to report that my NuForce dda-100 died on me.
I was using the nuForce to connect the RPi3 (Moode) into the USB port on the dda.
Now, the store that sold me the dda is offering a full credit of the price of the dda towards a NuPrime IDA-8. (I'll have to pay somewhere around $1350 to make the upgrade).
I have read that the IDA-8 is somewhat hit or miss regarding USB connectivity to Linux.
Has anyone ever tried Moode with an IDA-8 or some of the other IDA products from NuPrime?
I'm in kind of a hurry to decide, so any quick info would be highly appreciated.
Thanks in advance,
Rafa.
I was using the nuForce to connect the RPi3 (Moode) into the USB port on the dda.
Now, the store that sold me the dda is offering a full credit of the price of the dda towards a NuPrime IDA-8. (I'll have to pay somewhere around $1350 to make the upgrade).
I have read that the IDA-8 is somewhat hit or miss regarding USB connectivity to Linux.
Has anyone ever tried Moode with an IDA-8 or some of the other IDA products from NuPrime?
I'm in kind of a hurry to decide, so any quick info would be highly appreciated.
Thanks in advance,
Rafa.
MPD scan versus kernal
I experienced this issue with 3.5 and then forgot it as my HifiBerry Digi+ failed after 2 years of good service (as I was installing 3.6). I ordered an Allo Boss Dac which arrived yesterday. As I installed 3.6, I encountered the same issue:
In both cases, I changed the kernal to advanced RT as well as setting 'Performance', FIFO, and allowing multi-threading for SoX. After doing all that, I then set up my NAS (NFS). The initial scan seemed to go on forever, so I tried to log in via Putty, but the Pi was unresponsive as it was through the browser.
Again, in both cases, I powered down, rebooted successfully, changed the kernal back to standard, and successfully performed the initial scan. Then I reloaded the advanced kernal as before. Works beautifully.
I don't see this a problem to fix, but, if it is confirmed, a note in the install instructions would be good.
Skip
I experienced this issue with 3.5 and then forgot it as my HifiBerry Digi+ failed after 2 years of good service (as I was installing 3.6). I ordered an Allo Boss Dac which arrived yesterday. As I installed 3.6, I encountered the same issue:
In both cases, I changed the kernal to advanced RT as well as setting 'Performance', FIFO, and allowing multi-threading for SoX. After doing all that, I then set up my NAS (NFS). The initial scan seemed to go on forever, so I tried to log in via Putty, but the Pi was unresponsive as it was through the browser.
Again, in both cases, I powered down, rebooted successfully, changed the kernal back to standard, and successfully performed the initial scan. Then I reloaded the advanced kernal as before. Works beautifully.
I don't see this a problem to fix, but, if it is confirmed, a note in the install instructions would be good.
Skip
Can You post the results of
aplay -L
And of:
amixer controls
And if you have any suggestions as to how to improve the instructions or which parts were too technical or confusing, I am all ears!
Best regards,
Rafa.
Thanks Tim.
Adding the /home/pi/ fixed the problem with the copy command. I missed that when everything was displayed pushed together.
The issue with my Python script not working was that the file was in DOS format. Editting the file with nano and pressing Ctrl+o and the Ctrl+d changed the file to the correct format and now the display updates without issue. I had not noticed the "Converted from DOS format" message when I was editing the file. Maybe this will help someone else.
Sorry for the trouble.
Last edited:
Hi Skip,
Installing RT kernel also dedicates a single cpu for MPD. This may conflict with MPD/SoX multi-threading which wants to spawn resampling threads on all the cpus.
Just a guess.
-Tim
Hi Bryce,
I've been bit by editor formats before and its never obvious why code is not working and it always takes hours and hours to figure out.
-Tim
Thanks Tim,
I was unaware of that, and since I want top SoX upsample to 384K for the Allo Boss, RT is probably not the way to go.
Skip
Thanks Rafa and Jonners for your answers.
I followed the instructions of the post given by Jonners and it works well. Thanks a lot Jonners !
But what i would like to be able to tell Moode audio to stop if Spotify connect is playing and also stop spotify if Moode is playing. In fact i'm looking for a way to use spotify connect and moode audio as in the Rafa's youtube video "Moode - Spotify Connect proof of concept".
Rafa, do you have instructions to do it ?
Thanks again for your help
Bertrand
Hi,
Nice bit of work
If step 8 could be fully automated I'd be interested in trying to integrate this config into MoOde.
The zoom setting can be made via css. Can "minimal scrollbar" be automated via a config file setting?
-Tim
Wow, thanks Tim. That would be great if you could.
As I understand it an extension works if it is in the extensions folder. You could back it up and place it there and it would then apply to the scroll bar.
I got it working on Moode as it is in my view the best player of all the options.
I know Rune and I think Volumio have their own ways to get the touchscreen working. Frank at Rune integrated an option to turn on the screen in the ui and then I think modified the css to make it fit better. He also installed a keyboard so searches could be done from the touchscreen which I haven't worked out how to do yet. I don't know how Volumio do it but I think it is an option.
Sent from my iPad using Tapatalk
Hi Bertrand,
Precisely one of the reasons to choose librespot over Spotify-connect-web is because you have hooks on before start and after stop, which in Spotify-connect-web i had to 'cheat'. My implementation had a service checking by the second if the Spotify status had changed and called on MPD stop if it did.
It also modified Moode's database to reflect that Spotify was playing and modified the front end files to render the Spotify status and artwork.
It was not a small change by any means. And it was a proof of concept with a couple of un-resolved glitches: when Spotify was started and Moode was not playing, the Spotify client would start playing before my service could stop it (in order to make sure MPD was off), so you had a play-stop-play, since there was no real 'before play' hook.
So I abandoned the hope to have it tight and neat, and just stop one before starting the other.
Once Librespot produces a gapless playback version, I'll develop a true hook for it and post new instructions. But listening to concerts, classical and opera without gapless playback just makes no sense for me, so I'm waiting for what the developer described as a more or less easy implementation, but never got around to it. So I wouldn't hold my breath.
Sorry, the short answer is no, I don't have instructions for that.
Best regards,
Rafa.
Hi,
Nice bit of work
If step 8 could be fully automated I'd be interested in trying to integrate this config into MoOde.
The zoom setting can be made via css. Can "minimal scrollbar" be automated via a config file setting?
-Tim
xwit and xdotool? They allow you to control the keyboard and mouse from a script, while headless and emulating input devices.
Well, this approach is not 'wife friendly'.
I cannot expect my wife to switch on the desktop everytime to listen to music in the other room. The track name is not searchable from the Library view after the first time it seems. I have tried this using a Playbook, an Android device, a Windows laptop, a Windows desktop and an Android tablet, with a couple of browsers.
Searching by album name always works.
BTW: I have one suggestion. When we turn off the volume control inside MoOde, there is no need to show the volume circle as such. Can you add some option to make to disappear if the volume control is turned off from settings?
Overlayfs and Moode
[This message can safely be ignored by most users]
Returning to the subject of /var/www being read-only in the most recent MoOde Player releases (re #7865)
I had time today to look into overlaying a read-write directory onto /var/www. It turned out to be much easier than I expected because overlayfs has been part of the mainline linux kernel for more than 2 years (where have I been?) and is present in MoodeOS. There are alternatives like unionfs and aufs, but since it's already installed I'm going to drive overlayfs until I hit a speedbump.
The following is a technical summary of what I did and is not a tutorial. FYI, I'm working on a Linux laptop.
Proceed at your own risk.
All in superuser mode:
1. Write moode-img-r36.img to a uSD card, then mount the second partition of the card (which is the moodeOS root file system) to my filesystem and cd to it.
2. Create three new directories. Opinions vary about where new directories should go in a Linux file system; fist fights are rumored to have broken out in the Linux Standard Base project. I chose to create a new root-level directory to contain mine, but that's just me. The directory names are arbitrary; their semantics are established only by their declared use in fstab. The directories I created are:
3. Modify /etc/fstab to accommodate the overlay filesystem (note the diyaudio forum software folded the last line)
4. Plug the uSD card into a Raspberry Pi and power up.
To the casual eye, nothing has changed, but thanks to the magic of an overlay filesystem I can now delete, modify, or add files in /var/www.
Of course, that's not really what's happening. The "lowerdir" directory, where the squashfs file moode.sqsh is mounted, is unaffected. Any changes I make are recorded in new files in the "upperdir" directory, which here is /overlayfs/my-www, including the files "copied up" when edited. Files in the "upperdir" directory mask same-named files in the "lowerdir" directory.
I implemented this approach just this afternoon, so I'm still playing with it, but I foresee four advantages:
1. As in the pre-squashfs days, I can just start editing. Once an editing session is complete, I can rather immediately see how the changes affect MoOde Player.
2. I can always retract a change I've made by deleting the offending file (things get a little tricky here; I told you this isn't a tutorial). The original file, if any, will then be unmasked.
3. I can easily save my corpus of work, since only changed files are contained in the "upperdir" directory. (hmmm, git goodness in the face of a read-only filesystem, yay.)
4. I can let in-player software updates proceed. A new moode.sqsh replaces the old, but my changes are preserved. As long they aren't incompatible with the update, I can drive on. (Naturally, if they are incompatible, I'll have to make adjustments, but that would be true regardless.)
Please note the following from the kernel documentation
The moral is, never edit files in /overlayfs/my-www (if that's your "upperdir" directory) while MoOdePlayer is running.
As always, YMMV.
Regards,
Kent
PS - note that when Tim moved /var/www to a squashfs file, he also implemented a new /var/local/www directory to contain certain files which used to reside in /var/www, and modified his software to reference them. I conjecture these are the necessarily mutable files, e.g., files which MoOde Player might change as a result of a user configuration via the GUI and hence can't be read-only. Whatever their purpose, the approach outlined above does not address files in this directory. They can be edited in the usual way but tread cautiously!
PPS - Useful tech references:
https://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs.git/tree/Documentation/filesystems/overlayfs.txt
DSHR's Blog: Using the official Linux overlayfs
[This message can safely be ignored by most users]
Returning to the subject of /var/www being read-only in the most recent MoOde Player releases (re #7865)
I had time today to look into overlaying a read-write directory onto /var/www. It turned out to be much easier than I expected because overlayfs has been part of the mainline linux kernel for more than 2 years (where have I been?) and is present in MoodeOS. There are alternatives like unionfs and aufs, but since it's already installed I'm going to drive overlayfs until I hit a speedbump.
The following is a technical summary of what I did and is not a tutorial. FYI, I'm working on a Linux laptop.
Proceed at your own risk.
All in superuser mode:
1. Write moode-img-r36.img to a uSD card, then mount the second partition of the card (which is the moodeOS root file system) to my filesystem and cd to it.
2. Create three new directories. Opinions vary about where new directories should go in a Linux file system; fist fights are rumored to have broken out in the Linux Standard Base project. I chose to create a new root-level directory to contain mine, but that's just me. The directory names are arbitrary; their semantics are established only by their declared use in fstab. The directories I created are:
Code:
/overlayfs
/overlayfs/tc-www <-- this is where Tim's squashfs will be mounted
/overlayfs/my-www <-- this is the overlay where my modifications and additions will go
/overlayfs/work <-- this empty directory is an overlayfs requirement3. Modify /etc/fstab to accommodate the overlay filesystem (note the diyaudio forum software folded the last line)
Code:
$ more /etc/fstab
proc /proc proc defaults 0 0
/dev/mmcblk0p1 /boot vfat defaults 0 2
/dev/mmcblk0p2 / ext4 defaults,noatime 0 1
# a swapfile is not a swap partition, no line here
# use dphys-swapfile swap[on|off] for that
/var/local/moode.sqsh /overlayfs/tc-www squashfs ro,defaults 0 0
overlay /var/www overlay noauto,x-systemd.automount,lowerdir=/overlayfs/tc-www,upperdir=/overlayfs/my-w
ww,workdir=/overlayfs/work 0 04. Plug the uSD card into a Raspberry Pi and power up.
To the casual eye, nothing has changed, but thanks to the magic of an overlay filesystem I can now delete, modify, or add files in /var/www.
Of course, that's not really what's happening. The "lowerdir" directory, where the squashfs file moode.sqsh is mounted, is unaffected. Any changes I make are recorded in new files in the "upperdir" directory, which here is /overlayfs/my-www, including the files "copied up" when edited. Files in the "upperdir" directory mask same-named files in the "lowerdir" directory.
I implemented this approach just this afternoon, so I'm still playing with it, but I foresee four advantages:
1. As in the pre-squashfs days, I can just start editing. Once an editing session is complete, I can rather immediately see how the changes affect MoOde Player.
2. I can always retract a change I've made by deleting the offending file (things get a little tricky here; I told you this isn't a tutorial). The original file, if any, will then be unmasked.
3. I can easily save my corpus of work, since only changed files are contained in the "upperdir" directory. (hmmm, git goodness in the face of a read-only filesystem, yay.)
4. I can let in-player software updates proceed. A new moode.sqsh replaces the old, but my changes are preserved. As long they aren't incompatible with the update, I can drive on. (Naturally, if they are incompatible, I'll have to make adjustments, but that would be true regardless.)
Please note the following from the kernel documentation
The moral is, never edit files in /overlayfs/my-www (if that's your "upperdir" directory) while MoOdePlayer is running.
As always, YMMV.
Regards,
Kent
PS - note that when Tim moved /var/www to a squashfs file, he also implemented a new /var/local/www directory to contain certain files which used to reside in /var/www, and modified his software to reference them. I conjecture these are the necessarily mutable files, e.g., files which MoOde Player might change as a result of a user configuration via the GUI and hence can't be read-only. Whatever their purpose, the approach outlined above does not address files in this directory. They can be edited in the usual way but tread cautiously!
PPS - Useful tech references:
https://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs.git/tree/Documentation/filesystems/overlayfs.txt
DSHR's Blog: Using the official Linux overlayfs
Last edited: