02/26/2018 at 22:25 •
As I have already 3 production runs behind me I thought why not summarize some information about them (mainly the ripping speed) on a graph. This was done partly to confirm my suspection that Audio-CDs were being ripped very slowly. This has been confirmed by the data. The information gathered during the production runs has been summarized using the 'summarize-rip.sh' script (check scripts/ in repo) and plotted using gnuplot:
As you can see the ripping speed of Audio-CDs is much less than for data CDs (more time on the vertical axis). The reason for this is unclear as of now, it may be just that the Audio-CD disks are much more worn out causing the drive to work harder with error correction.
02/25/2018 at 22:52 •
Changed the code around a bit to make sure I gather all the logs generated by a single rip in the most simple way (using journald).
This allowed me to also support a "debugcam" - recording everyting happening on the robot workspace when a rip is executing. This uses a webcam working with ffmpeg to write a low-res low framerate video into the storage directory.
During this I discovered that ffmpeg can't record to VFAT because of a weird EINVAL returned by the kernel when trying to openat(). Discovered this using strace(), had no inclination to debug this further so I just changed the storage filesystem to be ext4. Reduces compatibility with Windows but meh.
02/12/2018 at 23:35 •
The controller has a LCD4USB off of Aliexpress connected to it in order to display various status and debugging information. This display is driven by lcd4linux where it's supported out-of-the-box by the 'LCD4USB' driver.