дядя Фёдор

Попробуйте дать фиксированный IP, а не автоматом. У меня тоже была проблема с этим - не успевает USB Wi-Fi законнектиться к точке доступа за время отведенное для получения адреса автоматом. Статический адрес работает. Проблему исправили в PGI 0.7.

Вы поставьте официальную прошивку и на ней попробуйте.

По умолчанию работает по версии 3. В скрипте 1.hdd было раньше vers=2, потому что в ядре не была включена поддержка версии 3 и это создавало проблемы при монтировании на серверы, у которых была версия 3 по-умолчанию (большинство серверов). Теперь это убрано из скрипта 1.hdd, потому что IPBox NFS клиент нормально работает с v3.

Телепатов здесь нет. Для чего вы пытаетесь подключить диск? Для записи каналов? Для чтения файлов которые уже есть на диске? Диск внутренний? Внешний? Читали HDD_ru.txt?

Карта карте рознь. Нужно пробовать. Никаких гарантий нет. Некоторые карты несовместимы с железом ресивера и никакой софт не поможет. Некоторые карты читаются железом, но софт-поддержка кривая. Короче, единственный способ это проверить или спросить у кого-то кто пользовал лично такую же точно карту.

Идет речь о версии протокола для подсоединения к стороннему серверу NFS, где ресивер выступает в качестве клиента. Смонтированный ресурс будет использоваться для записи каналов и таймшифта.

Если правильно настроен, то должен сам дозваниваться при перезапуске ресивера.

Пока ждем более-менее стабильной сборки. Отправьте на адрес [email protected] мейл с моделью ресивера и напоминанием что тестировать будем.

Разрешение видеовыхода НИКАК не влияет на запись каналов. Пишется то, что приходит со спутника, а не то, что выдается на видеовыход. В версии 0.6 используется NFS v3 по-умолчанию. Может у вас с этой версией проблема попробуйте поменять в скрипте монтирования /var/bin/init.d/1.hdd строчку: mount $NFS_REC -o rw,proto=$NFS_REC_PROTO,soft,nolock $DIR_MEDIA на вот эту: mount $NFS_REC -o rw,proto=$NFS_REC_PROTO,soft,nolock,vers=2 $DIR_MEDIA

Может стоит почитать HDD_ru.txt ?

Я посылал файлы на оба адреса. Не знаю, почему эстонские провайдеры блокируют Gmail. Выкладываю здесь. В архиве шаблон sbox.pot и русский вариант ru.po Можете редактировать либо тот, либо другой, какой будет удобнее. Файл должен быть в кодировке UTF-8. Позже могу выслать beta image (когда он будет готов) для того чтобы вы могли тестировать свои изменения сразу без перепрошивки. Удачи (и терпения). po.zip

если не работают каналы, снимайте логи и спрашивайте у шаровода почему не показывает. прошивка тут ни при чем.

проблема не только может быть в дистанции, но и в шнурке... есть шнурки со специальным набалдашником... http://en.wikipedia.org/wiki/Ferrite_bead http://ru.wikipedia.org/wiki/%D0%A4%D0%B5%...%BD%D0%BE%D0%BA

Тот идентификатор, что у вас теперь - это уже переключенный модем, с новым идентификатором, поэтому его в базе и нет. В базе есть непереключенный модем ATTRS{idVendor}=="12d1", ATTRS{idProduct}=="1003" ... После переключения режима у большинства железок меняется идетификатор Product. Если вы ручками переключили модем, вам больше не нужен usb_modeswitch (но в pgi.conf прописано должно быть, как и есть сейчас, для того чтобы были созданы /dev/ttyUSB*) У вас проблема сейчас в том, что в скриптах для chat или для peer что-то не так.

Идентификатора вашего устройства нет в драйвере сейчас. Добавим его когда будет бета PGI 0.7. Спасибо!

покажите что выдает команда lsusb (исполнять команду не через веб интерфейс, а через Telnet) Если бы там была модификация именно этого чипсета, то работало бы нормально. Думаю, там совсем другой чипсет.

почитайте первый пост в теме по 0.6.1

Где я писал, что она есть? Ее нет. И не планируется. И в PGI все что было сделано - это заменены скрипты монтирования устройства для записи. Всё, что я хотел сказать, это то, что NFS для записи - это хак. Так что все остальные "проблемы" - это последствия того, что никто не рассчитывал софт на работу в таком режиме. Поэтому удивляться "а чего в моем случае не работает, как мне хотелось бы" не стоит. Работает - замечательно, не работает - sorry, not our problem.

Тут нечего подразумевать. В официальных прошивках никто никогда не рассчитывал, что устройство записи будет сетевым и никаких оптимизаций софта или драйверов под это не делал.

Куда именно логинитесь: FTP, Telnet, SSH, Samba? В прошивках PGI для большинства вещей логин root, пароль relook

Два момента... В следующий раз, когда будете постить длинные логи, пользуйтесь тегом CODEBOX а не CODE. И второе, видимо, всё же лучше снимать логи по серийному порту, так как в файл идет буферизация и последние самые ценные сообщения просто не попадают в файл, так как зависли в буфере.... :(

Вовсе нет. Речь шла о том, что скорость передачи данных в этом случае больше зависит не от пропускной способности сети, а от приложения. Оптимизировать протокол NFS мы не можем. Он уже есть, работает превосходно, и никто его трогать не будет. Можете сами играться c параметрами rsize и wsize для команды mount. Оптимизировать приложение, которое шлет данные тоже в планах не было. Вообще удивительно, что люди так быстро забывают, что функция записи по сети напрочь отсутствует в официальных прошивках.

Меня интересуют логи а не просто сообщения "ресивер завис". Параметр DEBUG="yes" в pgi.conf и потом снимать лог из /var/log/sbox.init.log. Вообще-то не знаю где как, но (мой) ресивер не виснет, а медленно реагирует (иногда до 10-15 секунд) на нажатие клавиши.

Ну не все так просто... то, что вы померяли - это максимальная пропускная способность канала (то есть идеальный вариант). А вот скорость передачи конкретных данных будет зависеть от нескольких других вещей, которые подпортить жизнь могут очень сильно. Во-первых, скорость передачи полезных данных (payload) будет повышаться или понижаться в зависимости от того, насколько отдельный IP пакет будет наполнен полезной информацией (от нуля до MTU). Во-вторых размер TCP-окна влияет на "скорость" также, если используется протокол TCP и большой поток данных. В-третьих, сколько в каждом пакете будет чистой информации, а сколько служебной и зависит от протокола. Наример по SMB в каждом пакете куча "неполезной" информации, из-за чего реально нужно передать гораздо больше данных, чтобы один и тот же файл послать, скажем по SMB или по FTP. В-четвертых, сам софт, который что-то шлет в сеть может хреново слать (буферизация оптимизированная для локальных файлов, а не для сетки, и т.д.) Так что не стоит удивляться когда при всех вполне нормальных "тестах" передача данных будет менее чем оптимальной :(

http://gomel-sat.bz/forums/index.php?showtopic=1234