Home of the Squeezebox™ & Transporter® network music players.
Page 4 of 4 FirstFirst ... 234
Results 31 to 39 of 39
  1. #31
    Quote Originally Posted by Roland0 View Post
    More efficient way:
    Yes, I switched to stat this morning before I went to work but I didn't get a chance to test fully so I didn't post anything (sure!). I don't know why I went with the file comparison initially, that was stupid. Still need to work out the two anomalies I see in the output:

    1. Titles listed two or more times (false positive).
    2. Undetected track change, which is worse than a false positive.

    Wanted to investigate solutions to those before posting the stat version of the script. Thanks for the continued help Roland0.

  2. #32
    Watching the log isn't going to work I don't think, the timing of the writes don't really line up with song changes like I thought they did. It works fine when you are manually advancing from track to track, you get a new log entry immediately which reliably indicates that you need to query for changes. Intermittent writes to the log that aren't associated with a song change are pretty easy to deal with without a lot of extra external queries.

    The problem I just realized earlier is that towards the end of a song, about 5-10 seconds before the track changes, there's a log write but there is not one when the track actually does change, which sucks. So you kinda know that something may have happened when there's a log write but you don't really know for sure whether it's a track change, close to a track change or just something being logged for some other reason, without doing some detective work.

  3. #33
    Ok, here's the latest kludge:


    Open the lms telnet cli with nc and subscribe to playlist events. The sleep command keeps the pipe open. Script just waits here on a "newsong" event.
    Code:
    (echo -e "b8:27:eb:94:ae:63 subscribe playlist"; sleep 1h) | nc 192.168.1.201 9090 | ./sod-npd-tripwire.sh
    Contents of the tripwire script:

    Code:
    #!/bin/sh
    
    while :
    do
    read line
            if echo $line | grep -q newsong
            then
                    break
            fi
    done
    kill $(ps -ef | grep -m1 "sleep 1h" | cut -f1 -d " ")
    Receiving the text "newsong" breaks the tripwire and the main script proceeds to check and regenerate images and/or song info text as required. Then sets the tripwire again to wait for the next "newsong".

    It's ugly but it seems to be working ok.

    //edit, actually the "sleep 1h" thing is an issue. Originally I was using "cat" to keep the pipe to nc open but if you background it the process stops so i wasn't sure that would work. After the 1h sleep expires it closes the pipe to nc and so nc exits too, which is desired and I guess I figured the tripwire script would exit too but it doesn't, which makes sense now that I think about it.
    Last edited by sodface; 2018-12-08 at 23:34.

  4. #34
    I'll just tack an extra echo on after the sleep command and grep for it in the tripwire script. When the sleep timer expires the script doesn't need to kill the sleep process since it's already exited on it's own. On a newsong event the script does need to kill the sleep process so the pipe to nc will be closed and nc will exit. Just trying to clean up all the processes before the main loop sets the tripwire back up again.

    I think there might be a slim chance that the pgrep for the sleep pid could return a pid for sleep spawned by some other process, which is why I'm being specific with "sleep xx" and the -s 0 (even though I'm not really sure what a session is exactly) rather than just a killall sleep.

    Originally I thought the pids for the pipelined processes were consecutive which made it easy to start with the tripwire's pid and work back to the sleep pid, and they often are consecutive but not always.

    Code:
    (echo -e "b8:27:eb:94:ae:63 subscribe playlist"; sleep $scrsav; echo "exit") | nc 192.168.1.201 9090 | ./sod-npd-tripwire.sh
    A song with "exit" in the title would cause the tripwire to reset too but I don't think that really matters as it shouldn't happen very often.

    Code:
    #!/bin/sh
    
    while :
    do
    read line
            if echo $line | grep -e "newsong\|exit"
            then
                    break
            fi
    done
    
    if pid=$(pgrep -s 0 sleep $scrsav)
    then
      kill $pid
    fi
    The $scrsav is just the sleep time set in the config file. I'm thinking about using that as a screen saver sort of thing - if you pause playback there won't be any newsong events to break the tripwire so you'll have wait for the sleep timer to expire. Once it expires the main script can check for playback mode and if it's paused clear the screen and replace it with the screen saver image.

  5. #35
    Finally have all the main building blocks in place and working: track change notifications, background and cover art creation/manipulation/display, and track info text overlay. I tested quite a bit today and everything is working well with local tracks. Streams work also but cover art can be slow to change if a stream provides it at all. I've noticed my text display is correct but the cover art is one track behind. So I still have some things to tighten up. Need to test Roland0's customized cava still too.

    Hopefully sometime next week I'll post some installation instructions and provide a link for a single rolled up .tcz package. Then hopefully somebody else will give it a try!

  6. #36
    Roland0, I tried your cava version tonight and while it worked, it's not quite the same as the alsa loopback, especially when you press pause and no audio is playing. With alsa loopback method, the bars would immediately drop to zero. The shmem method, when paused, the bars would freeze at the levels they were at for a second or two and then start to grow taller even though no audio was playing.

    I'm in a hotel currently and the TV is smaller then the one I have at home and I'm using the builtin TV speakers, but here's a video of what I have so far:

    https://youtu.be/s2sfqKEwpTI

    My phone camera was struggling to stay focused but I think you can still get a feel for it.
    Last edited by sodface; 2018-12-11 at 20:55.

  7. #37
    Senior Member
    Join Date
    Aug 2012
    Location
    Austria
    Posts
    792
    Quote Originally Posted by sodface View Post
    Roland0, I tried your cava version tonight and while it worked, it's not quite the same as the alsa loopback, especially when you press pause and no audio is playing. With alsa loopback method, the bars would immediately drop to zero. The shmem method, when paused, the bars would freeze at the levels they were at for a second or two and then start to grow taller even though no audio was playing.
    Thanks for the feedback. The pause issue is a bit weird - it seems squeezelite doesn't clear the buffer exported for visualization when paused, so the input module detects the pause and clears CAVA's buffer, which, however, doesn't seem make any difference - I'll have to check why.
    Did you note any other differences to the ALSA version?

    BTW, squeezelite support has been added to CAVA (master branch, not release), so my modified version is not required anymore for this.

  8. #38
    Quote Originally Posted by Roland0 View Post
    Did you note any other differences to the ALSA version?
    I didn't test much more after I noticed the pause issue. Have you had a chance to look at that?

    I added a spinner animation that covers the screen while pCP is loading, it's removed and replaced by the cover art and cava once they are ready. The video link below shows the boot process and when the animation starts, which is later than I'd like. I'm starting it from /opt/bootsync.sh. There's probably an earlier place to start it - /etc/init.d/ maybe? I need the spriteview tcz loaded so it would need to be after tcz's are loaded and after the user backup is restored because that's where the png is. Still looks kinda cool I think! Screenshot provided for those that don't want to sit through the video, just imagine the spinner spinning.

    Animation loads around the 14 second mark.

    https://www.youtube.com/watch?v=NJ79WwyRqe8


    The rest of this post will document some issues and the fixes I implemented, if anyone sees any problems or has a better solution please let me know.

    Issue: cava bars show as numbers instead of bars when launching straight from the standard local console.

    Cause: The default console font doesn't have the right characters (glyphs?) for cava to display the bars properly. I was setting a utf-8 locale, loading the ncurses-terminfo.tcz, setting TERM=screen-256color (or something) and tmux to get everything looking good. Cava tries to set the font to a font included with Cava but so far as I can tell it expects the system to have the "setfont" command, which isn't present in pCP out of the box.

    Solution: Busybox provides "loadfont" so I'm using that prior to launching cava as well as turning off the cursor with the echo command:

    Code:
    echo -e '\033[?17;0;0c'
    loadfont < $home/fonts/cava.psf
    cava -p $home/config/cava.config
    As of now, I've eliminated the extra stuff above (tmux, terminfo etc) and can launch cava straight from the standard vty console.

    Issue: Cava colors not working.

    Cause: The TERM environment variable is set to "vt100" by default causing the cava bars to be white regardless of what color is set in the config file.

    Solution: Set TERM to "xterm". This gives you the 8 standard cava colors which is I think all I can expect to get with the standard console vty. This variable is staying set on reboots and I'm not sure how exactly. I thought it was resetting to vt100 on every boot and I was setting it to xterm either in my startup script or in /home/tc/.profile but I don't see the command anywhere?? So much for good note taking.

    Code:
    export TERM="xterm"
    Issue: Where's the best place to kick off my scripts and how?

    Solution: I now have one "run" script which is started on tc login by the /home/tc/.profile script. This should only be run once so use a run marker file and execute if it doesn't exist.

    Code:
    if [ ! -e /tmp/sod-npd/run ]; then
       sudo touch /tmp/sod-npd/run
       sudo openvt -s $HOME/sod-npd/scripts/sod-npd-run.sh
    fi
    Issue: Job control, backgrounding of scripts, scripts outputing noise to the console, etc.

    Solution: As you can see above, I'm launching the run script with "openvt" which starts a second vty and switches focus to it with the -s parameter. This vty is where cava runs. The run script starts the "main" script on a third vty, which sets up the telnet listener and does all the image processing and displays the text and artwork. I do not switch focus to this third vty so any output from the script is not visible and the pngview commands that display the images work just fine.

    Code:
    openvt $home/scripts/sod-npd-main.sh
    So if you have a keyboard connected, you can:

    "alt+f1" for the default tc login shell on vty1
    "alt+f2" for the normal "now playing" screen with cava and artwork
    "alt+f3" to view any output / errors etc from the "main" script doing most of the grunt work

    I know there are other ways to manage this but the multiple vtys using the openvt command was kind of a relief from a lot of little annoyances I was having with background tasks stopping and noise on the console even after redirecting output to /dev/null.

    Issue: I was initially using tmux to confine cava to a smaller area of the screen, at the bottom. After eliminating tmux and going back to the bare console, cava bars would want to consume the full height of the screen. I tried adjusting the bar height in the cava config script but I found that this worked ok at a set volume but adjusting the volume would make either the bars not move at all (lower volume) or exceed the desired confinement area (higher volume).

    Cause: The height value of the linux framebuffer needs to be adjusted to the desired value.

    Solution: Uncomment and set the overscan value in config.txt

    Code:
    # uncomment the following to adjust overscan. Use positive numbers if console
    # goes off screen, and negative if there is too much border
    #overscan_left=16
    #overscan_right=16
    overscan_top=600
    #overscan_bottom=16
    Other things I'm changing in config.txt
    Code:
    gpu_mem=256
    hdmi_force_hotplug=1
    hdmi_drive=2
    framebuffer_depth=32
    framebuffer_ignore_alpha=0
    Another minor annoyance you can see in the video, is the cava bars maxing out when audio first begins. Cava figures things out fairly quickly and does a pretty good job of keeping the bars at good levels after the initial "adjustment" period. Not sure there's much I can do about that, need to take a look at the config file options again.
    Attached Images Attached Images  
    Last edited by sodface; 2018-12-17 at 20:40.

  9. #39
    Senior Member
    Join Date
    Aug 2012
    Location
    Austria
    Posts
    792
    Quote Originally Posted by sodface View Post
    I didn't test much more after I noticed the pause issue. Have you had a chance to look at that?
    Not really, it's not obvious why clearing the vis buffer doesn't have the expected result, so I'll probably need a better understanding how cava actually works,

    I'm starting it from /opt/bootsync.sh. There's probably an earlier place to start it - /etc/init.d/ maybe?
    Solution: I now have one "run" script which is started on tc login by the /home/tc/.profile script. This should only be run once so use a run marker file and execute if it doesn't exist.
    If picoreplayer uses a sysV init, you can modify /etc/inittab to use agetty -a tc to automatically log in the tc user without asking for a password, which in turn will run the .profile script once the boot process has finished.

    Cause: The TERM environment variable is set to "vt100" by default causing the cava bars to be white regardless of what color is set in the config file.
    Solution: Set TERM to "xterm".
    TERM should be "linux" for the console.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •