Помощь
при экспорте большого количества фаилов в жпег на жесткий диск, столкнулся с нехваткой свободного места под операционной системой..
условие: каталог и РАВЫ и экспорт на физическом диске отличном от того на котором стоит опреционка.. в папке /темп/ нашел раздувающийся фаилик cr_sdk_№№№№№№№№.тмп
операционная система вместе с папкой для программ стоит на отдельном жестком диске объемом 20 гб из которых свободно 5,5 ГБ.. вот именно во время экспорта эти 5,5 гигов и съедаются назоиливым фаиликом.. конкретный пример на то чтоб экспортировать 278 фаилов размером до 2 мб мне понадобилось 4 раза закрывать лайтрум из-за нехватки места.
Такую же проблему нашел и на форуме адоба но путного решения не увидел.. от создателей одни только мэй би
внизу выдержка по той же проблеме но уже при обработке..ВОТ ССЫЛКА НА ФОРУМ КОМУ ИНТЕРЕСНО
Цитата
Hi Dan. I did some experimenting with the cr_sdk_NNNNNNNN.tmp file, and here's what I've found.
Win7x64, LR3-64bit,
i7 920, 6GB triple channel DDR3,
WD 2TB Black = Images
(1) 150GB WD 10k Raptor = OS
(2) 150GB WD 10k Raptor = Camera Raw Cache, 20GB
I have a large library, but for these tests I worked with only two DNG files, both originally from a Canon 5d mk II. Both are the 2010 process version, both have NR applied, and both have lens correction enabled.
At the start, both DNGs had basic color correction, white balance, and contrast adjustments.
"DNG A" had numerous localized adjustments - brushes, healing stamps, and gradiated filers already applied.
"DNG B" had no localized adjustments, so I was starting from scratch.
Lightroom was reportedly using ~1GB of "private working set" memory.
The cr_sdk_*.tmp file was non-existent.
After a few moments of working on DNG B, the .tmp file appeared at an initial size of ~136MB.
After about 10 minutes of working, the .tmp file had increased to ~510MB. At this point the interface was growing a little sluggish, but not unusable. For example sliders were jerky, and the ruby brush mask would take a moment to toggle on/off.
At this point I switched over to DNG A to make some minor tweaks. Simply switching images (no edits or adjustments made) caused the .tmp file to grow to ~1.3GB. In the process of opening DNG A, the Windows spinning ring appeared for about 20s, and the title bar for lightroom reported the application "unresponsive" during that time. I also noticed constant HDD thrashing. I made a few minor adjustments to this file, and the brushes and interface were extremely slow to respond. I use the mousewheel to grow/shrink the brush. When LR is behaving itself, the size change is fluid and fast. At this point in my experiment though, it was roughly 1 second per one step increase or decrease in brush size. Sliders were almost impossible to use, as each change required many seconds of waiting just to see the tick mark move on the bar.
Just for kicks, I then switched back to DNG B. Again the .tmp file ballooned - this time to 2.6GB. The application is so slow as to be unusable at this point. Task Manager reports Lightroom at 2.1GB of "private working set" memory.
The .tmp file size appears to be persistent as long as LR is open. Leaving the develop module does not shrink or remove the file.
Prior to exiting LR and restarting the app, my cpu/ram usage widget tells me 5,103MB of RAM is used out of 6,134MB. I exited LR and almost immediately my total used system RAM drops to 1,940MB - a change of 3,163MB. I didn't push as hard with this test, but on previous occasions I've seen LR take even more RAM - to such an extent that the OS itself starts swapping out necessary data. For example just opening the Start menu can take tens of seconds while the HDD thrashes away.
Win7x64, LR3-64bit,
i7 920, 6GB triple channel DDR3,
WD 2TB Black = Images
(1) 150GB WD 10k Raptor = OS
(2) 150GB WD 10k Raptor = Camera Raw Cache, 20GB
I have a large library, but for these tests I worked with only two DNG files, both originally from a Canon 5d mk II. Both are the 2010 process version, both have NR applied, and both have lens correction enabled.
At the start, both DNGs had basic color correction, white balance, and contrast adjustments.
"DNG A" had numerous localized adjustments - brushes, healing stamps, and gradiated filers already applied.
"DNG B" had no localized adjustments, so I was starting from scratch.
Lightroom was reportedly using ~1GB of "private working set" memory.
The cr_sdk_*.tmp file was non-existent.
After a few moments of working on DNG B, the .tmp file appeared at an initial size of ~136MB.
After about 10 minutes of working, the .tmp file had increased to ~510MB. At this point the interface was growing a little sluggish, but not unusable. For example sliders were jerky, and the ruby brush mask would take a moment to toggle on/off.
At this point I switched over to DNG A to make some minor tweaks. Simply switching images (no edits or adjustments made) caused the .tmp file to grow to ~1.3GB. In the process of opening DNG A, the Windows spinning ring appeared for about 20s, and the title bar for lightroom reported the application "unresponsive" during that time. I also noticed constant HDD thrashing. I made a few minor adjustments to this file, and the brushes and interface were extremely slow to respond. I use the mousewheel to grow/shrink the brush. When LR is behaving itself, the size change is fluid and fast. At this point in my experiment though, it was roughly 1 second per one step increase or decrease in brush size. Sliders were almost impossible to use, as each change required many seconds of waiting just to see the tick mark move on the bar.
Just for kicks, I then switched back to DNG B. Again the .tmp file ballooned - this time to 2.6GB. The application is so slow as to be unusable at this point. Task Manager reports Lightroom at 2.1GB of "private working set" memory.
The .tmp file size appears to be persistent as long as LR is open. Leaving the develop module does not shrink or remove the file.
Prior to exiting LR and restarting the app, my cpu/ram usage widget tells me 5,103MB of RAM is used out of 6,134MB. I exited LR and almost immediately my total used system RAM drops to 1,940MB - a change of 3,163MB. I didn't push as hard with this test, but on previous occasions I've seen LR take even more RAM - to such an extent that the OS itself starts swapping out necessary data. For example just opening the Start menu can take tens of seconds while the HDD thrashes away.
плиз хелп что делать? фотик Д7к... кто сталкивался отпишитесь либо посмотрите что у вас вытворяет этот лайтрум... есть правда одно но... с РАВами из Д60 такой проблемы небыло.
Цитировать
