RR и ждущий режим
 

Подскажите, пожалуйста, есть ли версия RR у которой бы нормально работал ждущий режим при включенных iList?

Пробовал довольно много версий (штуки 4 точно), во всех какие-либо проблемы.

Почти во всех версиях после ждущего режима очищаются iLists, если любой из списков был в момент ухода в ждущий режим на экране. Если iLists выключить, проблема исчезает, но слишком они удобные :-).
В последней, выложенной на сайте от 13.10.08 после ждущего режима RR перестает реагировать на изменения громкости, сделанные посредством AutohotKey, при проигрывании не двигается бегунок плеера.

Материнка не intel gly, в которой такие проблемы - норма, от скина не зависит.

Может у меня руки кривые? Или надо галки какие-то поставить в конфиге?

Именно ждущий, а не спящий режим?

Пожалуй, интерисуют оба режима.

У меня сейчас система стоит на флешке с HORM. Перед тем, как уйти единственный раз в спящий режим я выхожу из экранов с iList запускаю все возможные приблуды, типа навигации, потом увожу комп в спящий режим. А затем выходя из этого спящего режима используется ждущий режим во время поездок и пр. В случае, если что-то будет работать не так, перезагружу комп (можно и жестко) и он проснется еще раз из того же спящего состояния.

Формально при жесткой перезагрузке могу потерять данные на жестком диске, на который пишутся логи GPS, но реально это очень редко происходит.

Подскажи а как ты HORM реализовал и на какой системе? XP???

Да, на чуть модифицированной XP.
здесь http://www.compcar.ru/forum/showthread.php?t=2528 все написано.

Но предупреждаю! MS не шутит, когда не рекомендует входить в HORM с устройствами, на которых EWF отключен. И дело не только в том, что винда может не сбросить буферы записи. Она СОХРАНЯЕТ КЕШ ЧТЕНИЯ при уходе в HORM. Это приводит к тому, что видна помнит корневые директории, таблицы размещения файлов и прочее. Но во время прошлого вплывания их HORM эти данные уже могли измениться, а винда-то не в курсе...

А как ты решил проблемы заполнения под завязку оперативной памяти изменёнными файлами?

А в каком случае она может заполнится? Файл подкачки отключен, временные папки убраны или уменьшены. Все файлы, какие надо сохранить, сохраняем на другой диск (флешку).
У меня переполнялась если большие файлы распаковываешь.

Спасибо, буду пробовать!!!

1. поставил RamDisk в 300 мег. На нем своп 100 мег (без свопа винда плохо работает) и на нем же темп. Поэтому винда реально очень мало пишет на диск. Я посмотрел - размер памяти под буферы не превышает 10-15 мегабайт.

2. Если надо что-то большое записать на диск, выключаю EWF (там есть ключик, чтобы оно сразу выключалось без перезагрузки и потом лью файлы, потом включаю EWF и перезагружаюсь.

Прог я запускаю мало кроме RR и IGO из RR.

Для того, что бы не набирать каждый раз в терминале команду можно сделать cmd-файлы. Один для включения EWF, а другой для выключения.

Мои эксперименты с EWF упёрлись в невозможность автоматически отследить и предотвратить мёртвое зависание системы при переполнении памяти. К тому же надо и RR сохранять как-то плейлисты и текущую позицию в плейлисте, и СитиГиду куда-то пробки складывать...

А возможно ли в рамках EWF иль чего-то другого сделать полностью Read-Only диск без этих всех виртуальных записей?

А в какую папку RR листы сохраняет? Если в себя, то можно его установить на второй раздел диска.

А RamDisk не смотрел?

Можно раз в какое-то время в автоматическом режиме смотреть статус EWF и по результатам что-либо делать. Плейлисты можно на ramdisk складывать (но они копейки занимают, думаю пофиг. Активный список лежит в папке винампа), ситигид тоже туда же можно запихнуть. У меня гиг памяти и я ездил всяко больше недели без перезагрузок, у меня объем памяти под EWF не превышал 15 мегабайт.

В общем, могу сказать, про поэксперементировав с HORM пришел к выводу, что из-за проблем с использованием не RеadOnly дисков, лучше буду пользовать просто EWF на системной флешке. На отдельном жестком диске при этом лежит вся музыка, логи GPS, в будущем - файлы видеорегистрации.

НЕЛЬЗЯ! это скорее всего приведет к ошибкам файловой системы.Почему - я писал выше, связано с кешем чтения, который сбрасывается в Hibernate и потом используется.

Я спящий режим не использую. У меня стоит только EWF.
При выходе из спящего при большом обьеме оперативной памяти время загрузки даже больше, чем при простом включении.
При использовании твой программы видеозаписи делаю все настройки и сохраняюсь. Потом все работает и пишется в оперативку. Какую видеозапись надо сохранить , тот файл копирую на съемную флешку.

Вроде б, взаимноисключающие высказывания...
Прокомментируй, плиз, это. :)

Смысл в том, что сама технология EWF не накладывает каких-либо ограничений на использование не Read Only носителей. Единственное - если есть не Read only носители, то питание надо выключать нормально, как в обычной системе.

А вот если используется HORM, то возникает серьзная проблема: винда не обнуляет кеш при выходе в хибернейт и выходе из него, а пишет этот кеш в файл хибернейта. И в результате получается забавная глюка, которую отловить можно далеко не сразу.
Пример: у тебя есть пустой диск d: на который можно писать. Пофиг, этот тот же физический диск или нет, главное что не ram drive. Ты с этим пустым подключенным диском ушел в HORM. Система при этом помнит, что диск - пуст!
Ты загружаеься из HORM и пишешь на этот диск какой-нить файл, а затем перегружаешься, а точнее еще раз всплываешь из того же HORM.
У системы - де жа вю. Она помнит, что диск ПУСТ. Точнее, помнит пустую корневую директорию и часть(!) MFT/FAT.
Дальше вариантов много:
1. Система очищает эту часть кеша, поскольку кеш заполняется данными с EWF диска (он же тоже кушируется на чтение). И тогда ты увидишь записанный файл и даже сможешь его прочитать.
2. Ты сразу посмотришь на диск и увидишь его пустым.
3. Ты увидишь, что файл есть, но когда начнешь писать что-то еще на диск, то запишешь новый файл в то же место, в котором уже лежит ранее записанный файл! Это самое неприятное последствие и я именно на него наступил. То есть у тебя лежал на диске текстовый файл, а после выхода из HORM, в место на диске, в котором лежит содержимое текстового файла, будет писать видео тот же CamGrabber. И файл текстовый вроде лежит нередактированный, но открываешь его, а в нем - маленький кусок видео файла...

Пункт 3 - это то, на что я напоролся. Есть еще прикол связанный с тем, что винда при заходе в Hybernate/HORM по-моему не сбрасывает отложенную запись, но от этого можно уйти, не записывая на диск перед уходом в спячку. Результат тот же - порушенная файловая система...

То есть - при уходе в HORM в системе не должно быть запоминающих устройств, на которые возможна запись. Ram disk - не в счет. Либо использовать USB жесткий диск/флешку и на момент ухода в HORM его отключать, либо - не иметь устройств с разрешенной записью.
SATA хоть и позволяет горячее подключение, по моему опыту с ним такой прикол не проходит, по крайней мере моя система сама на лету его не подхватывает, требуется обновлять устройства.