Helo lukjs!
Welcome to the forum, and thank you for your contribution. You made me think, and dig deeper into bootlocal.sh. I haven't seen this problem myself before, and are now running a different setup (seashell's alsa-plugin) so I couldn't really test the bootlocal.sh discussed here. (I did run this setup before, but without camillaGUI)
But now I have done a series of test with the default bootlocal.sh. And it shows that I do have the problem now. I didn't just notice, since I have no extra commands to execute.
So, something has changed in my system. And your'e wright about the problem with the command line:
But it is not entirely a problem of "tee". tee works fine with other commands than pcp_startup.sh, when used in bootlocal.sh. So it's somehow the combination of pcp_startup.sh and tee, that sometimes don't finish, and makes bootlocal.sh freeze. I didn't notice it at start, but if you run "ps" to list running processes, these 2 lines shows that bootlocal.sh never finish - ever...
pcp_startup.sh makes a whole bunch of stuff, depending on the current configuration of pCP. So there are plenty of possibilities to make it act different from time to time, and for different users.
But there is a better(?) work-around than just cutting of tee. We want logging... don't we? My suggestion keeps logging to file, on the expense of screen output. Who can read what is rushing by on the screen anyway..?
Replace tee with an ordinary redirect like this:
When I were at it, I also verified that bootlocal.sh is run by user "tc" at boot. I was tricked to believe it was root, but its not. By adding this line in bootlocal.sh, the name of the user running the script is printed in the log file:
This means, as you mentioned, that the statement "sudo" is needed in the following command line:
or - if you don't dare to use "tee", even if it should work:
And for starting camillaGUI - I can only guess...
User "tc" can't run Jesper's script "/home/tc/StartServer.sh", because the use of a "su" command, that will ask for a password, that cant be supplied. I don't understand how it can work for Jesper..?
If user root runs it, no password is needed. So prepending sudo should solve the problem of starting camiilaGUI. Give this a try:
This might also freeze bootlocal.sh. If so try:
To wrap all this up, a complete bootlocal.sh might look like this:
I can not, and have not tested this version myself. There might be typos..!
What a mega post - please bare with me...
/ πr
Welcome to the forum, and thank you for your contribution. You made me think, and dig deeper into bootlocal.sh. I haven't seen this problem myself before, and are now running a different setup (seashell's alsa-plugin) so I couldn't really test the bootlocal.sh discussed here. (I did run this setup before, but without camillaGUI)
But now I have done a series of test with the default bootlocal.sh. And it shows that I do have the problem now. I didn't just notice, since I have no extra commands to execute.
So, something has changed in my system. And your'e wright about the problem with the command line:
Code:
/usr/local/etc/init.d/pcp_startup.sh 2>&1 | tee -a /var/log/pcp_boot.log
Code:
920 root 0:00 {bootlocal.sh} /bin/sh /opt/bootlocal.sh
1104 root 0:00 tee -a /var/log/pcp_boot.logBut there is a better(?) work-around than just cutting of tee. We want logging... don't we? My suggestion keeps logging to file, on the expense of screen output. Who can read what is rushing by on the screen anyway..?
Replace tee with an ordinary redirect like this:
Code:
/usr/local/etc/init.d/pcp_startup.sh >> /var/log/pcp_boot.log 2>&1
Code:
echo "User=$USER" >> /var/log/pcp_boot.log
Code:
sudo /usr/local/bin/squeezelite-cdsp.sh start 2>&1 | tee -a /var/log/pcp_boot.log
Code:
sudo /usr/local/bin/squeezelite-cdsp.sh start >>/var/log/pcp_boot.log 2>&1And for starting camillaGUI - I can only guess...
User "tc" can't run Jesper's script "/home/tc/StartServer.sh", because the use of a "su" command, that will ask for a password, that cant be supplied. I don't understand how it can work for Jesper..?
If user root runs it, no password is needed. So prepending sudo should solve the problem of starting camiilaGUI. Give this a try:
Code:
sudo /home/tc/StartServer.sh 2>&1 | tee -a /var/log/pcp_boot.log
Code:
sudo /home/tc/StartServer.sh >>/var/log /pcp_boot.log 2>&1
Code:
#!/bin/sh
#echo DEBUG_1 >> /var/log/pcp_boot.log
# put other system startup commands here
GREEN="$(echo -e '\033[1;32m')"
echo
echo "${GREEN}Running bootlocal.sh..."
#pCPstart------
/usr/local/etc/init.d/pcp_startup.sh >> /var/log/pcp_boot.log 2>&1
#pCPstop------
#echo DEBUG_2 >> /var/log/pcp_boot.log
sudo /home/tc/StartServer.sh 2>&1 | tee -a /var/log/pcp_boot.log
#echo DEBUG_3 >> /var/log/pcp_boot.log
sudo /usr/local/bin/squeezelite-cdsp.sh start 2>&1 | tee -a /var/log/pcp_boot.log
/usr/local/bin/squeezelite-cdsp.sh status 2>&1 | tee -a /var/log/pcp_boot.log
#echo DEBUG_4 >> /var/log/pcp_boot.logWhat a mega post - please bare with me...
/ πr
Last edited:
Thank's a lot pi r...
I hope you can maybe guide tomorrow, as i'am not home before late???
I only have a comment about the tc -c / sudo user stuff.
I implemented my StartServer.sh script to avoid running the GUI as "root", and as you can see the script is actually running it as user tc ::
If we say, that bootlocal.sh is ran as root, then when executed with su tc -c, we change user to tc and execute... When this is ran as root, we shall not give password.
In other distros, files like this can also be forced to run something as normal user the same way...
But as i wrote earlier, this bootlocal.sh can be tricky, and i allway's did stroggle some to control it's behaviour
The pcp_startup.sh script is complicated and large as pi r also mention, and things can go wrong, especially when we run thing's which are not a part of the pCP-package.
Fra8123 i will reread my guide, but i don't have the time to correct if there are error's...
If we are lucky, pi r will help you ... It's actually his setup you are trying to install as SuperPlayer v3...
Anyway GREAT help guy's here, this is the real force of such community
Jesper.
I hope you can maybe guide tomorrow, as i'am not home before late???
I only have a comment about the tc -c / sudo user stuff.
I implemented my StartServer.sh script to avoid running the GUI as "root", and as you can see the script is actually running it as user tc ::
I had all the year's with piCore belived that bootlocal.sh was executed as root, and i also think that i read it somewhere... I'am in doubt now, but nevermind that for now
If we say, that bootlocal.sh is ran as root, then when executed with su tc -c, we change user to tc and execute... When this is ran as root, we shall not give password.
In other distros, files like this can also be forced to run something as normal user the same way...
But as i wrote earlier, this bootlocal.sh can be tricky, and i allway's did stroggle some to control it's behaviour
The pcp_startup.sh script is complicated and large as pi r also mention, and things can go wrong, especially when we run thing's which are not a part of the pCP-package.
Fra8123 i will reread my guide, but i don't have the time to correct if there are error's...
If we are lucky, pi r will help you ... It's actually his setup you are trying to install as SuperPlayer v3
...Anyway GREAT help guy's here, this is the real force of such community
Jesper.
I think I have read a comment from Henrik some time, about the GUI shall not be run as root. So it makes sense.
I guess you could change the "su" in StartServer.sh to:
Code:
sudo su tc -c ....If bootlocal.sh is run as root or tc on boot...
We have always used sudo to start squeezelite-cdsp.sh. And I guess that was for a good reason. I have a faint memory that I earlier "assumed" bootlocal.sh was run by tc, and got surprised when you claimed it was root, some day ago. And as lukjs confirms: it don't work without sudo. If root runs bootlocal.sh, sudo wouldn't be needed.
Which makes it very strange how you can get StartServer.sh to run in bootlocal.sh at boot...
/ πr
Hi Pi r,
following your suggestion and using the string:
everything works and I can read the log.
Thanks for your help, I think now everything is setup properly.
This is another topic but I am now wondering if there is a way to change the camilladsp config as function of the format of the file pcp is playing. Do you know if this is possible?
following your suggestion and using the string:
everything works and I can read the log.
Thanks for your help, I think now everything is setup properly.
This is another topic but I am now wondering if there is a way to change the camilladsp config as function of the format of the file pcp is playing. Do you know if this is possible?
Backgrounding bootlocal.sh is a good thing. Especially in situations when it hangs... But I fail to see how backgrounding is relevant here..?
As far as I understand the problem is the execution of /usr/local/etc/init.d/pcp_startup.sh from within bootlocal.sh. Under certain conditions (pCP-config depending?) and in combination with piping its output to tee, it never finishes, and so bootlocal.sh freezes.
In the process list (long after boot), bootlocal.sh and tee remains as unfinished processes. But pcp_startup.sh is missing, indicating that pcp_startup.sh itself actually does finish. The log file also looks complete. Something in the end of pcp_startup.sh seems to make tee upset, and tee hangs...
Good point...
I believe most of us here run v6.1.0. I do, and I'm pretty sure Jesper (lykkedk) do so too.
Hi, I am sorry for my late response, but it is a very busy period.
I set up camilladsp on picoreplayer 7.0.0 and everything works fine with the adjustment of the bootlocal file as suggested.
I am using my DAC also for my TV audio and my problem now is to keep camilladsp working when I change the input of my DAC. So far, everytime I want to listen to some music with LMS, I need to restart picoreplayer or run bootlocal file.
Do you have any suggestion to fix this issue?
Thanks
I set up camilladsp on picoreplayer 7.0.0 and everything works fine with the adjustment of the bootlocal file as suggested.
I am using my DAC also for my TV audio and my problem now is to keep camilladsp working when I change the input of my DAC. So far, everytime I want to listen to some music with LMS, I need to restart picoreplayer or run bootlocal file.
Do you have any suggestion to fix this issue?
Thanks
Thanks Jesper,
yes, the program terminates, but looking around I found this workaround which works well and I fixed it
Autostart Squeezelite | piCorePlayer documentation
Did you have something similar in mind?
I am sorry for my brain storming, but I am now wondering if I can use camilladsp also to apply room correction to the TV audio. There must be a way to connect the TV to picoreplayer, like this HiFiBerry DIGI+ I/O hat, but haven't found yet how to configure pcp to manage this input. Via LMS and its plugin WaveInput?
I know there could be timing issue, but at the moment I am neglecting this issue.
Luca
yes, the program terminates, but looking around I found this workaround which works well and I fixed it
Autostart Squeezelite | piCorePlayer documentation
Did you have something similar in mind?
I am sorry for my brain storming, but I am now wondering if I can use camilladsp also to apply room correction to the TV audio. There must be a way to connect the TV to picoreplayer, like this HiFiBerry DIGI+ I/O hat, but haven't found yet how to configure pcp to manage this input. Via LMS and its plugin WaveInput?
I know there could be timing issue, but at the moment I am neglecting this issue.
Luca
Hi Jesper,
here is my bootlocal, still the same with last changes:
I solved the issue related to DAC input selection making the script:
I still few points that I am trying to investigate/understand:
here is my bootlocal, still the same with last changes:
I solved the issue related to DAC input selection making the script:
and adding to /opt/.filetool.lst the path to this file:
copying what I found in the picoreplayer website.
I still few points that I am trying to investigate/understand:
- the possibility to apply room correction to TV audio, connection the TV to raspberry and picoreplayer. One choice may be to use Airplay and apple TV (I can use an App to watch the TV where I am), but the quality of the audio is not that good and I am not totally sure if the signal goes through camilladsp. The preferred option would be to connect optically the TV, but not clear how. In both case the possible delay introduced by signal processing is still an open.
- I understand camilladsp is very powerful and it is important to make it very flexible, but it is not clear to me why I should have different settings depending on sample rate: Nyquist frequency is changing together with the signal bandwidth but unless someone can hear frequency well above 20KHz, the dps setting will remain the same.
In my understanding more interesting may be changing the setting over different file formats or resolution (different resolutions may require different setting, or maybe someone would like to remove dsp to mqa file).
- or camilladsp can be used to change portion of the spectrum emphasizing/attenuating tones depending on what you are listening. And in this case, it would be great having camilladsp integrated into LMS with few settings (customizable) to select together with the music.
Luca
Lukjs.
Thank's for your'e comments, please inform if you figure stuff out along the way.
Regarding this ::
Someone here on diyaudio are in progress of integrating camilladsp into LMS somehow. Let me see if i can find that htreat... hang on
*EDIT* Here it is :: Dynamic transcoding and convolution in Logitechmediaserver
Jesper.
Thank's for your'e comments, please inform if you figure stuff out along the way.
Regarding this ::
Someone here on diyaudio are in progress of integrating camilladsp into LMS somehow. Let me see if i can find that htreat... hang on
*EDIT* Here it is :: Dynamic transcoding and convolution in Logitechmediaserver
Jesper.
Last edited:
For anyone that had trouble getting this to work, any ideas where to start looking? I followed the guide, and my problem is not (only) in the bootlocal stuff but that the squeezelite-cdsp.sh won't even start when run manually.
Rpi4 and fresh piCore 6.1
Rpi4 and fresh piCore 6.1
Code:
tc@piCorePlayer:~$ sudo squeezelite-cdsp.sh start
+ Starting Squeezelite player and CamillaDSP...
+ Starting daemon /usr/local/bin/samplerate-daemon.py
ERROR - Could not start /usr/local/bin/camilladsp.
ERROR - Could not start /usr/local/bin/squeezelite.
ERROR - Could not start /usr/local/bin/samplerate-daemon.py.Sorry, ignore my previous post for now, I was a bit fast there. I think I have this up and running now, GUI is working and there is sound output in my system, and I can verify that the signal is being processed through the filter settings specified in 44100.yml.
Now please if anyone can explain to me like I'm three:
- My system is constantly locked at 44.1 kHz even if I play higher res. What do I need to configure to actually get filters for other resolutions, and the automatic switching?
- I want to use externally created files for my filters, and not enter them by hand. have been using .dbl files before but I can use something else if they ar not compatible.
Where do I put them and what do I need to configure to have Superplayer/CDSP read these files?
Thanks in advance
Now please if anyone can explain to me like I'm three:
- My system is constantly locked at 44.1 kHz even if I play higher res. What do I need to configure to actually get filters for other resolutions, and the automatic switching?
- I want to use externally created files for my filters, and not enter them by hand. have been using .dbl files before but I can use something else if they ar not compatible.
Where do I put them and what do I need to configure to have Superplayer/CDSP read these files?
Thanks in advance
Another update, sorry for the spamming.
After som retries everything works with the sample rate and filter switching, when playing LOCAL files. Only. I also use the Qobuz plugin for streaming, and this is when everything gets sent as 44.1 kHz to my DAC, no matter the source format.
Anyone got this working together with Qobuz?
After som retries everything works with the sample rate and filter switching, when playing LOCAL files. Only. I also use the Qobuz plugin for streaming, and this is when everything gets sent as 44.1 kHz to my DAC, no matter the source format.
Anyone got this working together with Qobuz?
** Update **
Hey guy's here
I felt it was time to reboot my SuperPlayer, and so the journey begins...
For a long time i wanted to make the camillagui install the right way, aka' the piCore (piCorePlayer) way with in ram .tcz extensions.
So i created a lot of .tcz's with help from my freinds over at TinyCore Linux...
Everything is working as expected, but i need tester's (brave one's)
Take a look... The hole camillagui is packed into .tcz...
GitHub - Lykkedk/SuperPlayer-v8.0.0--CamillaGUI-v0.6.0: SuperPlayer-CamillaGUI .tcz extensions the right way of doing it
Jesper.
Hey guy's here
I felt it was time to reboot my SuperPlayer, and so the journey begins...
For a long time i wanted to make the camillagui install the right way, aka' the piCore (piCorePlayer) way with in ram .tcz extensions.
So i created a lot of .tcz's with help from my freinds over at TinyCore Linux...
Everything is working as expected, but i need tester's (brave one's)
Take a look... The hole camillagui is packed into .tcz...
GitHub - Lykkedk/SuperPlayer-v8.0.0--CamillaGUI-v0.6.0: SuperPlayer-CamillaGUI .tcz extensions the right way of doing it
Jesper.