Bug 105777 - tmp overflow slow processor
Summary: tmp overflow slow processor
Status: RESOLVED UNMAINTAINED
Alias: None
Product: kaudiocreator
Classification: Unmaintained
Component: general (other bugs)
Version First Reported In: 1.12
Platform: unspecified FreeBSD
: NOR wishlist
Target Milestone: ---
Assignee: Gerd Fleischer
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-05-16 19:32 UTC by Kyryll A Mirnenko aka Mirya
Modified: 2025-06-10 16:05 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed/Implemented In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Kyryll A Mirnenko aka Mirya 2005-05-16 19:32:46 UTC
Version:           1.12 (using KDE 3.4.0, compiled sources)
Compiler:          gcc version 3.4.2 [FreeBSD] 20040728
OS:                FreeBSD (i386) release 5.4-RELEASE-p1

When got slow enough processor to make ripping much faster than encoding the interm. data (wav data processed by slow running encoder) is being collected in /tmp filling it until no space left. That would be nice to check if there's space to rip next track and wait for encoder to finish current file and free some space if so
Comment 1 Nigel Stewart 2006-09-21 07:10:10 UTC
I posted the following in relation to
Bug 94722: Limit number of extracted songs

But I think these comments are more relevant here...

----------

I think it is handy to be able to rip CDs continuously and let things queue up for encoding providing I have enough disk space and my CPU is kinda slow.  Perhaps some status information about the disk space consumption and available disk space, would go along with some kind of disk space limit for temporary files.  One complication is that the temporary files and encoded files are not necessarily on the same partition. :-)

The most basic thing that can happen is that ripping can be paused when there is too little space available, and can resume once space becomes available.  In this situation the ripper would be waiting for the encoder to catch up a bit.

"too little space" = available space - 1GB < size of next ripped track

This ensures that CD ripping leaves room for other system use of temporary files, I suppose the 1GB "breathing space" could be adjustable to something smaller or larger, as needed.

Is it possible to allocate space for the entire track up-front, to ensure the entire track can be ripped reliably even if available disk space gets suddenly gobbled up elsewhere? 
Comment 2 Justin Zobel 2021-03-09 03:51:40 UTC
Thank you for the bug report.

As this report hasn't seen any changes in 5 years or more, we ask if you can please confirm that the issue still persists.

If this bug is no longer persisting or relevant please change the status to resolved.
Comment 3 Christoph Cullmann 2025-06-10 16:05:20 UTC
This project is unfortunately no longer maintained.

If a new maintainer wants to step up and take care, the project is archived here:

https://invent.kde.org/unmaintained/kaudiocreator

You can just clone it in your private namespace on invent.kde.org and if you have started to work on it and fixed/implemented something get it reviewed and the project unarchived.

Sorry for the inconveniences.