"Getfile" command

Does the "getfile" command support deletions when it is used in the following way?
getfile C:\path_to_folder\testfile.mp3 /delete
If not, can it be added to the new features list please?
This would solve a problem I have with streamarchive files not overwriting existing files.



 
The getfile command expects a folder as a parameter, not an individual file. It won't work this way.

The streamarchive command will overwrite existing file if you specify the same file name.
 
The getfile /oldest /delete command often fails to delete the file at its completion if the command in the multiples feature is immediately followed by another file playout. Is this due to too much intensive CPU activity? If so, is there a workaround that allows me to delete the file a bit later (that is, can the delete command have a short delay applied so the events don't coincide? I have found this works with streamarchive on - if it is followed by another event, a 2 sec pause after the streamarchive command and before the next event seems to solve the problem of streamarchive crashing.
 
The getfile /oldest /delete command often fails to delete the file at its completion if the command in the multiples feature is immediately followed by another file playout. Is this due to too much intensive CPU activity?
CPU is not an issue here. RadioBOSS waits for some time to ensure the file is not locked, and then tries to delete it. If the following lpayback command also affects the file that is supposed to be deleted - it may cause the delete operation to fail. Do you use the latest RadioBOSS by the way? I see there were some getfile-related bugs fixed in the latest update.
 
The latest version still has this problem. The delete process fails when I have a new scheduled task immediately after. At 11:59:59 the program ends and tries to delete (but fails and there is no error). At 12:00, the news starts successfully. As a consequence, the previous program stays in the folder and cannot be manually deleted without a complete reboot as it is locked and has zero content. Can this be fixed? If the getfile / oldest / delete runs again the next day at the same time it tries to delete the same file again instead of that day’s new file and the playback fails. Currently I have to reboot RB every day just to make the file go away...
 
As a consequence, the previous program stays in the folder and cannot be manually deleted without a complete reboot as it is locked and has zero content.
Even if delete operation fails, RadioBOSS will not use this file for playback for getfile command. I'm not sure why delete operation could fail. Does it happen always or only sometimes?
 
RB does not need to use this file for playback. It needs to use the new one on the following day.

It happens almost every day. On the next day, if the previous day’s file has been deleted successfully, the getfile command finds the oldest file in the folder and plays it. If the previous day’s file fails to delete then the next day there are two files in there that getfile /oldest tries to access. If there is just playlist after the getfile /delete operation then it works fine. Somehow the scheduled event that follows the file causes it to lock. The folder from which two streamarchive saved files are selected (getfile /oldest then getfile /newest) is used to repeat programs recorded at 12 and 1 pm respectively at 5pm and 6pm. If you don’t believe me I’ll show you a screenshot!
 
You record shows using streamacrhive command, and then play the same files using getfile command with /delete option, right?
 
Yes that is correct. Streamarchive saves oldestfile.mp3 in first hour, then newestfile.mp3 in second hour. Getfile with /oldest and /newest is used to play the files later in the day then delete after play. This happens every day. Both files are recorded and replayed after a short news break. It is usually the first hour that refuses to delete because there is a news event in between (in multiples play). The second hour rarely has any scheduled event after it.
 
We are continuing to have strange behaviour with files refusing to delete when getfile command is used. This happens because the file recorded by streamarchive often stays locked to RadioBoss and any attempt to delete the file fails. To prove this we created a batch file including the run command (del /f /q z:\artscafe\ *.mp3) and scheduled it to run several hours after the program played to air. On the first day it worked (/f forces delete and /q bypasses the permissions). Today the same command only deleted one of the two files in the artscafe folder. Repeated attempts to delete the file by clicking run now failed to move it. Only a reload of RB enables it to be unlocked again. Can you please look into this bug as it requires daily manual intervention.
 
Chris that's very odd behavior as yes Radioboss locks the file its playing you say its still locked afterward .I don't want to say something and no disrespect but have you checked the drive for errors with disk checking software? I was able to delete all of the 60 second segments apart from the one that is recording by the Mp3 Recorder locally which I would expect I am using 6.2.4.2 x64 Advanced Edition version . I hope this helps am on Windows 11 H2. You said are using The GetFile operation which retrieves a file from a host. Is this host online or on local network have you mounted the drive on a drive letter ?
I tried but it said getfile was not recognised as a cmdlet, function, script file etc
getfile C:\Documents\djsoft.net\RadioBOSS_1183139368\Stream Archive\20230227_16-16-16.mp3 /delete
 
Last edited:
Can you please look into this bug as it requires daily manual intervention.
We were not able to confirm it. When it fails to stop an encoder for some reason (stopping an encoder means also unlocking a file) it will show an error message in the log. There were also improvements made (for the next update) to improve diagnostics, maybe it'll help to diagnose what happens in your case.
 
Further investigations: the file does not get locked during the streamarchive process so it’s not anything to do with the encoder. It appears to be related to the play process initiated by getfile which is scheduled 5 hours after the recording time. Windows process checking reveals RB as the only software remaining linked to the locked file.

We will do another disk check to see if that might be related. The getfile command retrieves the file from the local drive and works sometimes but not always. Because the file is locked, it cannot delete it after playing but theee is no error in the log. Driving us nuts! Recording programs for delayed replay is a common broadcast requirement so it would be appreciated if some attention could be given to this issue thanks.
 
Further investigations: the file does not get locked during the streamarchive process so it’s not anything to do with the encoder. It appears to be related to the play process initiated by getfile which is scheduled 5 hours after the recording time. Windows process checking reveals RB as the only software remaining linked to the locked file.
The file is unlocked right after its playback is over.

About the deleting process. It tries to delete the file, if deleting fails, it will try again and again, indefinitely. The file will stay on "delete" list until it's deleted. That's why there's no error message if deleting fails.
 
I tried defragging the disk but it made no difference. At the moment we have two files in the single directory. When we play them back we run getfile oldest and then getfile newest with the oldest file deleting first. Sometimes the former works, but at least 3 times a week it does not. The latter (newest) seems to work OK. Because this has been unreliable I will try some other way of playing the files, such as in series, and using a del command in a windows batch file to delete the files. I'll let you know how that goes!
 
Defragging is going to make any issue worse. It will move objects around on the drive relocating them in contiguous area.

To check any drive, you need to firstly run the checkdsk /f or equivalent for your O/S from a command shell or terminal with admin privileges. on WIndos you can get to this by right clicking the windows button. I would also suggest you additionally on Windows you run SFC /SCANNOW from a command shell or terminal with admin privileges too to check your drivers are all in order. Both of these items will require a large amount of time on a large drive to execute and maybe need to be planned. These commands are all documented online, and I would suggest if you were in any doubt to follow some of the good online guides which include DISM.
 
Yes thanks HMMMM I'm well aware of the disk check and SCANNOW procedure - but as the machine is used 24/7 we have to pick our times! :)
 
Back
Top