Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Overwriting during Internet recording #65

Open
Ducke1001 opened this issue Jan 22, 2025 · 9 comments
Open

Overwriting during Internet recording #65

Ducke1001 opened this issue Jan 22, 2025 · 9 comments

Comments

@Ducke1001
Copy link

If I record from the Internet and the file already exists, the recording stops. This happens particularly often with the Gingles. But even when a new song comes on, the recording is not continued.
Unfortunately, the "-f" option for overwriting is not available here.

@stsaz
Copy link
Owner

stsaz commented Jan 23, 2025

Hi!

But even when a new song comes on, the recording is not continued.

Next file should be created as usual, depending on what output file template you're using. Can you attach logs when it is not the case?

Unfortunately, the "-f" option for overwriting is not available here.

When using file names from the server's meta data, overwriting your existing files on disk is insecure behaviour -- it's better if you'd use @counter or @nowtime to generate unique file names.

@Ducke1001
Copy link
Author

The command:

"phiola.exe" -Log phi.log "https://play.radioking.io/nordic-chillout-radio/736489" -tee "D:\Records\@artist - @title.aac"

gave the following log:

08:36:05.871 #12576 INFO file-write: *2: D:\Records\Max Cooper - Rule 110 (feat. Joe Mcbride) (Synkro Remix).aac: written 1844KB
08:38:45.725 #12576 INFO file-write: *4: D:\Records\ - Jingle Nordic FeelGood.aac: written 63KB
08:42:23.970 #12576 INFO file-write: *5: D:\Records\Firas Tarhini - So Slowly.aac: written 1704KB
08:48:20.512 #12576 INFO file-write: *7: D:\Records\Cannons - Fire For You.aac: written 1164KB

Phiola overlooks some files. They are created but not written. The file size remains at 0. File 1 was also not written and remained at 0 size. I assume the file was too small because the title had been playing for a while.

When using file names from the server's meta data, overwriting your existing files on disk is insecure behaviour -- it's better if you'd use @counter or @NowTime to generate unique file names.

I see it as an advantage to be able to save by artist and title. Perhaps recordings could automatically add an index if the file already exists.

@stsaz
Copy link
Owner

stsaz commented Jan 25, 2025

gave the following log

I would need the full debug log to understand what was happening.

I see it as an advantage to be able to save by artist and title.

You can just use @counter. @artist - @title.aac, for example.

@Ducke1001
Copy link
Author

Here is a debug log:
phi.log

All files were written at once only after recording was complete. The file size remained at zero for that long. I hope it helps. Otherwise I'll try again.

You can just use @counter. @artist - @title.aac, for example.

One option would be to set the counter at the end of the file. In the beginning it is unfavorable for sorting.
But no matter how, you would have to rename each recording afterwards, since the counter in the file name is not needed.

@stsaz
Copy link
Owner

stsaz commented Jan 26, 2025

All files were written at once only after recording was complete.

It's a bug, will be fixed in the next version, thank you!

I see it as an advantage to be able to save by artist and title. Perhaps recordings could automatically add an index if the file already exists.

Well, I currently see two options here:

  • Use the template that will generate unique file names
  • Or just ignore the error messages when the file already exists

Adding file name counter automatically only in case the output file exists won't add any benefit, because the new output file will have the same content as the previous one (e.g. artist - title.aac == artist - title (1).aac), and you will delete the second file anyway.

@Ducke1001
Copy link
Author

Ducke1001 commented Jan 26, 2025

It's a bug, will be fixed in the next version, thank you!

Thank you very much for your effort and the active development of Phiola.

Adding file name counter automatically only in case the output file exists won't add any benefit, because the new output file will have the same content as the previous one (e.g. artist - title.aac == artist - title (1).aac), and you will delete the second file anyway.

No, not necessarily. Recordings (songs) from internet radio are never exactly the same length. Sometimes they are mixed with other tracks or are interrupted by jingles. I always look for the best version and then delete the others.

@stsaz
Copy link
Owner

stsaz commented Feb 1, 2025

All files were written at once only after recording was complete.

This should be resolved in 2.3-rc8.

Perhaps recordings could automatically add an index if the file already exists.

I thought for a moment about that and couldn't come up with the plan how to properly pass this user's intention via CLI (because this definitely must not be default behaviour). Maybe you can suggest a CLI option how you think it's best to do it?

@Ducke1001
Copy link
Author

I like streamripper's approach here (https://github.com/streamripper/streamripper).
It saves incomplete titles in a separate folder and you can decide what you want to do with them. Here are the corresponding options that are offered:

-o (always | never | larger | version)
Overwrite tracks in complete directory
When streamripper rips tracks they are put into the incomplete
directory until they are finished. Normally, they are then moved into
the complete directory. However, when the track is already there, can
use this option to tell streamripper what you want to do. There are
three choices: always, never, and larger. If you dont include any of
the -o options on the command line, the default is "-o larger" for
version through 1.63.4, and "-o version" starting with 1.64.5.
If you use the "-o never" option, this tells streamripper to never
overwrite any existing file in the complete directory.
If you use the "-o always" option, this tells streamripper to always
overwrite any existing file in the complete directory.
If you use the "-o larger" option, this tells streamripper to overwrite
an existing file in the complete directory if the newer file is larger.
If you use the "-o version" option, this tells streamripper to keep
both versions, renaming the existing file.
-t
Dont overwrite tracks in incomplete directory
Normally streamripper writes the files in the incomplete directory, and
then moves it to the base directory (the complete directory) when it is
done. If the file with the name of the track already exists in
incomplete, it will overwrite the old track. When you use the -t flag,
however, this will tell streamripper to backup the existing file in
incomplete (appending a version number), and then create the new file.
This is useful for streams that dont have meta-data. Because these
streams only have a single file, reconnects will cause overwriting the
existing file, which is not desired.
-T
Truncate completed tracks in incomplete directory
When you are not overwriting files in the complete folder, the
duplicate files will normally stay in the incomplete folder. This
option tells streamripper to truncate the files to zero bytes in the
incomplete folder if they are a duplicate.

But of course this is more complex to implement.

Alternatively, an option -add (if the file already exists, create a new file with an index) or -dskip (don't skip the file if it already exists) might be possible.

@stsaz
Copy link
Owner

stsaz commented Feb 3, 2025

option -add (if the file already exists, create a new file with an index)

This would require the code that either iterates in a loop to find the correct index or reads the contents of the directory -- in either case several to many system calls in the place where we can/should just create the file in 1 single operation.

Personally, I don't see how this approach is any better than just using @counter or @nowtime at the end of file name, but let's keep this issue open for now...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants