CDR Tickets

The Processing Results report explained what happened. The script performs two passes, one to verify that the sets are correctly constructed for processing, and the second for performing the retrieval. The second pass is not performed if the first pass fails, as it did in this case.

Retrieval aborted by failed MP3 path checks

means exactly what it says. The first pass found a dozen separate problems, and each one is reported in the output you captured in your screenshot. Fix those problems and everything should work correctly.

Thanks Bob! The reported problems were in the Week_2021 file which was used for troubleshooting the sftp problems for Amy K. It shouldn't be in the directory. I removed it and it seems to be working now. Thanks!

I haven't gone back to the original tickets to confirm Alan's reasoning for having the software behave this way, but I would guess what you'll find if you do go back and read those tickets is that he wanted to prevent corrupted audio sets from being moved from the s/FTP server (to which you have access and where you can remove or fix the problems with incorrectly assembled sets) to the CDR file system (to which you—and the developers for that matter—don't have direct access, meaning we would need the assistance of CBIIT to get problem sets removed). Make sense? It's a common, sound principle behind many decisions in software development: if the program encounters unexpected problems, have it stop, report the problems, and back away to avoid the risk of making the problems worse. That's what Alan has done here. I would have done the same thing.