video jukebox using Raspberry Pi 3B

  booting Debian... I built a plywood "chassis" (bottom and back panels), with finished pine front panel.  Black steel top cover is scavenged from some old piece of audio or video equipment. Here you can see the poplar reinforcement beam I had to fit into the metal cover, so that it would carry the weight of a big monitor on top without bending excessively. Each button presses one of the microswitches, which ground the GPIO lines which are otherwise pulled high to 3.3v, using the 2.2k resistors visible in the foreground. The boards holding the red & blue LEDs can be seen at the top, spaced in between the three button assemblies.  The LEDs shine upon the paper liners, which are visible from the front through the wide gaps around each button shape.  This forms a gradient of diffuse purple light, coming through the cracks. You can see the folded sheet-aluminum heatsink which is superglued to the top of Pi CPU chip.  Not exactly "up to code", but gets rid of the...

(So as you can see, I shirked the opportunity to learn Python (yet again), and  just did it with a shell script.  Results are a little janky, like you can see a text cursor blinking on top of the cover images, and it takes a little while to start playing a selected video, during which time you see a Linux text screen with login prompt, but overall this gets the job done reliably, it seems.) The main script, called svp.sh, is located under /home/pi.  It has to be run as root, unless you take some care to set up permissions and groups and stuff. You also need to create the file /etc/systemd/system/svp.service as shown, and you'll need to add a line to /etc/fstab as indicated if you want to use a removeable USB stick for the video data, as I have done. The script svp.sh requires the free software programs "fim" and "mpv".  These permit images and videos to be displayed directly on the Linux framebuffer, i.e., the "text console", without needing to run X W...

 /dev/sda /mnt ext2 defaults,nofail 0 0 #  Notice that I'm using ext2 here, not VFAT.  This is necessary.  See #  my recent post "VFAT: too skinny for me".

  [Unit] Description=S. Video Player [Service] User=root WorkingDirectory=/home/pi Restart=always RestartSec=3 ExecStart=/home/pi/svp.sh [Install] WantedBy=multi-user.target

#!/bin/bash # Notice, must be run explicitly as "/bin/bash", not "/bin/sh", # because advanced bash features like arrays are used. # svp.sh VID_LOCATION='/mnt/videos' VID_SUFFIX='.mpg' IMG_LOCATION='/mnt/images' IMG_SUFFIX='.jpg' IMG_NOTFOUND='notfound.jpg' VID_CMD='mpv --fs --ontop --no-resume-playback --audio-device=alsa/hdmi:CARD=vc4hdmi,DEV=0' IMG_CMD='fim -N -q' exec 2> /dev/null # Delay for 10 seconds after startup before trying to display anything. # This is a kluge (obviously). The .service file has the # "WantedBy=multi-user.target" line, which is supposed to pause activity # until the system is ready, but this doesn't work. Maybe I should be using # a different .target? Anyway, without the delay here, the first image # does not get displayed, instead there is just a mess of console text on # the screen until the first button is pressed, because the initial...

Just FYI, in case you, like me, are trying to build a digital system to play videos originally ripped from VHS tapes.  Many of these tapes are recorded with "copy protection", known by the brand name "Macrovision".  This system involves putting out-of-spec signal levels into the vertical blanking interval of the video signal.  Somehow, old-school VHS players -- even if they don't "know about" the copy protection -- are still able to play these tapes, but if you try to copy the signal through the patch cables to another recorder (such as an AV-to-USB converter cable), the irregular sync signals either cause the video to be unusably erratic, or in many cases, the capture software recognizes the Macrovision and refuses to record it (even though it displays it on the screen!). The solution is to pass the video signal through something which breaks down the signal and re-constitutes it, with freshly-created sync pulses.  I'd have thought this would be t...

OK, so the wiring is quite simple. 5 volts DC power supply and HDMI cable are "permanently" wired into the back of the unit.  The HDMI cable simply plugs directly into the Pi (regular HDMI for RPi3B, the OPiZero2 needed micro-HDMI).  There is a wooden cable-clamp to relieve any strain on the Pi from outside forces on the cable.  The 5 volts line runs to my home-made circuit board, which is connected to the switches and LEDs of the front panel, and also runs to the Pi. The three buttons (back-arrow, play, forward-arrow) are cute-looking wooden actuators which push three roller microswitches.  These each connect a given Pi I/O line to ground, versus three 2.2k resistors pulling up to 3.3v (which is an adequate logic H even for 5v systems).  I've used the same physical pin numbers on the Raspberry Pi as I used with the Orange Pi, even though the connectors are not identical in naming or even size (the RPi one is the longer extended type with 40 pins). The switch ha...

This is a tale of warning. So, probably like many people, I thought I'd build a little special-purpose video player.  This one is for my daughter, who loves Disney movies, but the basic principle of turning a general-purpose computer into a fixed-purpose video player with a simple interface, has surely come up millions of times.  Indeed, HDMI video capability is probably one of the main reasons people choose a "Pi" type computer, instead of something like Arduino. So I thought, this should be pretty straightforward.  Heh heh.  First, I built some nice-looking hardware, basically a set-top box with three buttons: back-arrow, play, and forward-arrow.  The idea is that the arrows will choose which video to play, putting up a still cover-image for each video in turn as it scrolls through a directory full of videos (stored on removable USB stick).  When the desired video is on-screen, pressing Play will of course play it (and subsequent Play presses will pause/u...