Would it be possible to upgrade squeezelite to squeezelite to 1.8.7-1052?
According to the owner there are still problems with the previous versions
(Issue streaming VoiceRSS mp3 content to piCorePlayer - Page 3)
According to the owner there are still problems with the previous versions
(Issue streaming VoiceRSS mp3 content to piCorePlayer - Page 3)
Hi
May I suggest the following radiostream to add to the default streamlist ?
-- http://www.radioson.ru:8009/clubJazz.RadioSon.ru.mp3 --
on: Jazzclub radio stream - Listen online for free
Jazzclub from France
May I suggest the following radiostream to add to the default streamlist ?
-- http://www.radioson.ru:8009/clubJazz.RadioSon.ru.mp3 --
on: Jazzclub radio stream - Listen online for free
Jazzclub from France
Hi,
Sure, I can bump it for moOde 4.1 update 🙂
In the meantime you can make it yourself by running the commands in COMPONENT 5 of the Build Recipe. This will always compile the latest version thats been committed to the Squeezelite Git repo.
I just compiled it and its 1.8.7-1052
-Tim
Hi Koda,
I don't want argue about this (repetition comic...)
Before do anything I suggest you to take a look at how to manage the swap:
You can start with this link (this is clear !): How to: Configure Swappiness in Ubuntu - Knowledge eXchange
If you had already corrected the gmusicapi installation process in the mosbuild_worker, you could see the problem on a RPi2 too (without swap)
With the really great report of Kent i'had made my test on a RPi1 but B version (with 512Mo... I can't have my A version before 2 month maybe, so i'll buy another one next week just for test) if i just keep the default parameters of raspbian i can't install gmusicapi, because when it compile xml it need at his maximum more than 650Mo (by default it use a 100Mo swap file and 440Mo of memory without the video memory... 540Mo in total so i think the RPi2 can't install gmusicapi without swap too), i had this message :
and others like this one.
But in fact i succeed to install it, what I do :
- just remove 100 of the line CONF_SWAPSIZE=100 of the file /etc/dphys-swapfile, like this, linux take what's needed by the process.
After the installation process, i can just use the swapiness parameter for deactivate the swap or just turn off with the swapoff command, with this we can reactivate it with swapon.
The gmusicapi process take more than 1H45 without problems on RPi 1B
The entire process take approximatively 5 hours.
And in conclusion: All problems i'had before on the RPi3 installation process with Wifi came of that missing swap i think... because since, i haven't any problem (but it's not sure anyway).
Good luck.
I don't want argue about this (repetition comic...)
... at least not "just"
Before do anything I suggest you to take a look at how to manage the swap:
You can start with this link (this is clear !): How to: Configure Swappiness in Ubuntu - Knowledge eXchange
If you had already corrected the gmusicapi installation process in the mosbuild_worker, you could see the problem on a RPi2 too (without swap)
With the really great report of Kent i'had made my test on a RPi1 but B version (with 512Mo... I can't have my A version before 2 month maybe, so i'll buy another one next week just for test) if i just keep the default parameters of raspbian i can't install gmusicapi, because when it compile xml it need at his maximum more than 650Mo (by default it use a 100Mo swap file and 440Mo of memory without the video memory... 540Mo in total so i think the RPi2 can't install gmusicapi without swap too), i had this message :
Code:
virtual memory exhausted: Cannot allocate memory
Compile failed: command 'arm-linux-gnueabihf-gcc' failed with exit status 1and others like this one.
But in fact i succeed to install it, what I do :
- just remove 100 of the line CONF_SWAPSIZE=100 of the file /etc/dphys-swapfile, like this, linux take what's needed by the process.
After the installation process, i can just use the swapiness parameter for deactivate the swap or just turn off with the swapoff command, with this we can reactivate it with swapon.
The gmusicapi process take more than 1H45 without problems on RPi 1B
The entire process take approximatively 5 hours.
And in conclusion: All problems i'had before on the RPi3 installation process with Wifi came of that missing swap i think... because since, i haven't any problem (but it's not sure anyway).
Good luck.
Last edited:
Hi,
What about just leaving swap enabled. The file is only 100M and other than during the Build Process, its never going to be used.
-Tim
100M is not enough for gmusicapi (650Mo needed / 512-64+100=548 544,5 in real). If i don't touch anything like I said before, I have a problem of memory. I must change to higher value (300 for a 512Mo, so 550 for a 256Mo) or just leave the subject to the system (yes, it's better than me) and remove 100 (sorry I've made only 2 complete test on the RPi1, this is a veeeeery long process).
Just test to install gmusicapi on RPiZero (not RPi2 like i wrote before) with swap enabled with configuration by default and maybe like me you will have the same message (i haven't already test to do this, maybe tomorrow if the time is clear), else maybe take a look at this solution.
Regards
Last edited:
4.0 not working on Pi 7” Touchscreen
Same here, I repeated the whole install. This time the build went smoothly from beginning to end, but I still get the same behaviour as Morias.
The system becomes unresponsive only after I enable localui. Localui starts shortly after the Pi boots, leaving me a short period where I can ssh into the pi and disable localui. If I do that, everything works ok again (except local display). When I enable localui again, the same happens again.
If I log to the Pi through ssh immediately after boot, I get these messages on the screen when the crash happens. After this point, the system becomes unresponsive: I cannot log in through ssh, and in the existing ssh session I can type commands, but then nothing happens, I don’t get any output. The Touchscreen does not react to taps.
This looks like a kernel panic, maybe the X server? Maybe chromium? Can we apt-get upgrade, to maybe get new versions, or will that break moode?
Same here, I repeated the whole install. This time the build went smoothly from beginning to end, but I still get the same behaviour as Morias.
The system becomes unresponsive only after I enable localui. Localui starts shortly after the Pi boots, leaving me a short period where I can ssh into the pi and disable localui. If I do that, everything works ok again (except local display). When I enable localui again, the same happens again.
If I log to the Pi through ssh immediately after boot, I get these messages on the screen when the crash happens. After this point, the system becomes unresponsive: I cannot log in through ssh, and in the existing ssh session I can type commands, but then nothing happens, I don’t get any output. The Touchscreen does not react to taps.
Code:
Message from syslogd@moode at Feb 1 13:52:01 ...
kernel:[ 31.562077] Internal error: Oops: 5 [#1] SMP ARM
Message from syslogd@moode at Feb 1 13:52:01 ...
kernel:[ 31.668745] Process TaskSchedulerFo (pid: 919, stack limit = 0xa9292210)
Message from syslogd@moode at Feb 1 13:52:01 ...
kernel:[ 31.675438] Stack: (0xa9293f00 to 0xa9294000)
Message from syslogd@moode at Feb 1 13:52:01 ...
kernel:[ 31.679789] 3f00: 8028d100 a9293f38 b700f950 00000063 5c3434a0 ffffff9c 6102c6e8 a9293f6c
Message from syslogd@moode at Feb 1 13:52:01 ...
kernel:[ 31.687960] 3f20: b700f950 00000063 a9293f54 a9293f38 802826d8 802ed064 00000000 00000000
Message from syslogd@moode at Feb 1 13:52:01 ...
kernel:[ 31.696130] 3f40: ffffffea 00004000 a9293fa4 a9293f58 80276730 80282664 a9293f6c 8013ad54
Message from syslogd@moode at Feb 1 13:52:01 ...
kernel:[ 31.704301] 3f60: a9293f8c 5c3434a0 a9292010 00000000 b9638010 b9b63990 5c3434a0 00000064
Message from syslogd@moode at Feb 1 13:52:01 ...
kernel:[ 31.712472] 3f80: 5c3434a0 00000063 0000014c 80108244 a9292000 00000000 00000000 a9293fa8
Message from syslogd@moode at Feb 1 13:52:01 ...
kernel:[ 31.720643] 3fa0: 801080c0 80276698 00000064 5c3434a0 ffffff9c 6102c6e8 5c3434a0 00000063
Message from syslogd@moode at Feb 1 13:52:01 ...
kernel:[ 31.728814] 3fc0: 00000064 5c3434a0 00000063 0000014c ffffff9c 6102c620 6102d6d8 6102c6bc
Message from syslogd@moode at Feb 1 13:52:01 ...
kernel:[ 31.736984] 3fe0: 5ff43ef4 6102c5e4 5ff2da58 7560bc6c 20000010 ffffff9c 55555555 55555555
Message from syslogd@moode at Feb 1 13:52:01 ...
kernel:[ 31.769772] Code: ea000002 e1530004 e1a03001 0a00000b (e5931008)This looks like a kernel panic, maybe the X server? Maybe chromium? Can we apt-get upgrade, to maybe get new versions, or will that break moode?
You can make a "sudo apt-get update" & "sudo apt-get upgrade" without break moOde.
Cheers
Oh ok. I had assumed that Linux swap file was dynamic and would expand as needed.
Its kind of a messy issue...
-Tim
im struggeling to build an sd card with moodeaudio 4
when i want to make a moodeaudio 4 sdcard with the given commands
should i download the file rel-stretch-r40.zip too ?
or is it not necessary then ?
when i want to make a moodeaudio 4 sdcard with the given commands
should i download the file rel-stretch-r40.zip too ?
or is it not necessary then ?
It's "dynamic" only if you remove the size of this parameter.
After this you can just leave the swap alone and deactivate or activate it on the fly with swapiness like it is describe in the link on my previous post (the answer to Koda) without restart in anyway.
Regards
Hi,
Apt-get update and upgrade are run at the beginning of the build in STEP 3.
If these two cmds are not run in the very beginning there will be a lot of breakage.
-Tim
I checked those links but did not find anything that said Linux will expand or shrink the swap file dynamically.
Did I miss a link?
-Tim
No, i don't send link about this.
But it's wrote juste before the parameter in the /etc/dphys-swapfile file else in the man page of dphys-swapfile.
Good luck.
Gmusicapi dont use so much memory with Kent's method Moode Audio Player for Raspberry Pi
The real problem is during lxml task 😉
The real problem is during lxml task 😉
Last edited:
Sorry i'hadn't more precise... but lxml is a part of the gmusicapi installation.
Cheers
Ok I see the params in /etc/dphys-swapfile
Why not just go with a dynamic swapfile?
-Tim