Помогите мне решить мою проблему с NPR Media Player

во-первых, позвольте мне извиниться за этого становится немного технической. Несколько недель назад, я обнаружил, что при использовании медиа-плеер НПР (например, нажмите кнопку 'слушать шоу' - это то, что я использовал в качестве теста) поток будет остановить внезапно через минуту или три. Я не мог сделать поток, чтобы перезапустить без перезагрузки страницы. Теперь, я предположил, что это проблема с НПР игрока и Linux (или просто баг в свои вещи вообще), поэтому я начал копать, ниже то, что я пробовал на сегодняшний день (обратите внимание, что мы выбрали вариант, чтобы перейти к последней вещью, как мне кажется, я знаю, что является причиной проблемы).

Примечание: все тесты были проведены, в целях единообразия, на чистую установку хрома без pluggins работает. Моя машина с Ubuntu 10.10x64.

первое, что я всегда стараюсь, я отключил все вещи брандмауэра в системе (НПВ, по умолчанию запретить все, разрешить СШ). Никаких изменений, брандмауэр, резервное копирование для всех дополнительных испытаний, если не указано иное. В любом случае, НПВ является stateful, поэтому он начал подключения на номера указанные на разных портах будет продолжать работать. Я удалил ~/.macromeda и ~/.компания Adobe папок перезапускается (просто чтобы быть уверенным) и попробовал. Программа по-прежнему мерзли. Я решил, что проблема может быть с моей установки Flash, так что я очистил версия у меня была (и дома опять папок). Я установил 64-разрядную версию Flash из ППА. Это не произвело никакого эффекта. Я решил, что проблема может быть с версией Flash, так что я удалил версию x64 и установить стандартную версию х32, которая поставляется с Ubuntu. Не повезло. Вернулся к версии x64 для консистенции, я решил установить 64-битным клоном мини '' моей системы в VirtualBox. Я смог запустить медиа-плеер без проблем. Я rsynced (в режиме архива) мой домашний каталог с моей реальной машины на виртуальную машину (с мостовая сеть, поэтому он был полностью виден в сети). Я также использовал несколько трюков, чтобы установить все те же программы (и хранилища) с реальной машины на виртуальную машину. Я еще мог слушать плеер. Я решил, что проблема с моей установки (в конце концов, она пережила два крупных обновления версия). Как у меня /дома/ на отдельный раздел было легко переустановить и использовать тот же трюк с #6 снова моя система и работает в течение около часа. Я по-прежнему есть проблемы с НФОР медиа-плеер. На данный момент же пришел. В работе я использую проводное соединение, а дома я использую беспроводную связь. По некоторым причинам я забыл, что у меня возникли проблемы, и используется в обзоре медиаплеер в минувшие выходные. Низкий, и вот это сработало просто отлично у себя дома на беспроводной (Примечание: по разным причинам, я не мог проверить это на проводной дома). Следуя из #6, я решила, что проблема была либо что-то с сетью на работе или еще что-то с моей учетной записью. Так как последний был легче, чтобы проверить, я создал новую учетную запись в системе и использовать это в работе. Медиа-плеер работал. В недоумении, я решил посмотреть трафик с tshark (текстовой брат, как wireshark) - х, чтобы защитить невинных, я ХХХ.24.200.ХХХ: команду sudo tshark -я через eth0 -р -т -р "ИС.аддр == ХХХ.24.200.ХХХ && ИС.аддр == ХХХ.166.98.ХХХ"

как и следовало ожидать, там были тонны и тонны пакетов, но каждый раз, когда игрок замер, это то, что я получил

[dиода d17]

команду sudo tshark -я через eth0 -р -т -р "ИС.аддр == ХХХ.24.200.ХХХ && ИС.аддр == ХХХ.166.98.ХХХ"

08:42:20.718602 ХХХ.24.200.ХХХ -> ХХХ.166.98.ХХХ протокол TCP [протокол TCP ZeroWindow] 56371 > макросреда-ФТС [АСК] сл=6 АСК=819134 выиграть=0 Лен=0 ТСВ=396475 ЦЭР=495713325 08:42:21.050183 ХХХ.166.98.ХХХ -> ХХХ.24.200.ХХХ ПТС [ПТС ZeroWindowProbe] макросреда-ФТС > 56371 [АСК] сл=819134 с ACK=6 победит=65535 Лен=1 ТСВ=495713362 ЦЭР=396475 08:42:21.050221 ХХХ.24.200.ХХХ -> ХХХ.166.98.ХХХ протокол TCP [ПТС ZeroWindowProbeAck] [протокол TCP ZeroWindow] 56371 > макросреда-ФТС [АСК] сл=6 АСК=819134 выиграть=0 Лен=0 ТСВ=396508 ЦЭР=495713362 08:42:21.680548 ХХХ.166.98.ХХХ -> ХХХ.24.200.ХХХ ПТС [ПТС ZeroWindowProbe] макросреда-ФТС > 56371 [АСК] сл=819134 с ACK=6 победит=65535 Лен=1 ТСВ=495713425 ЦЭР=396508 08:42:21.680605 ХХХ.24.200.ХХХ -> ХХХ.166.98.ХХХ протокол TCP [ПТС ZeroWindowProbeAck] [протокол TCP ZeroWindow] 56371 > макросреда-ФТС [АСК] сл=6 АСК=819134 выиграть=0 Лен=0 ТСВ=396571 ЦЭР=495713425 08:42:22.910354 ХХХ.166.98.ХХХ -> ХХХ.24.200.ХХХ ПТС [ПТС ZeroWindowProbe] макросреда-ФТС > 56371 [АСК] сл=819134 с ACK=6 победит=65535 Лен=1 ТСВ=495713548 ЦЭР=396571 08:42:22.910400 ХХХ.24.200.ХХХ -> ХХХ.166.98.ХХХ протокол TCP [ПТС ZeroWindowProbeAck] [протокол TCP ZeroWindow] 56371 > макросреда-ФТС [АСК] сл=6 АСК=819134 выиграть=0 Лен=0 ТСВ=396694 ЦЭР=495713548 08:42:25.340458 ХХХ.166.98.ХХХ -> ХХХ.24.200.ХХХ ПТС [ПТС ZeroWindowProbe] макросреда-ФТС > 56371 [АСК] сл=819134 с ACK=6 победит=65535 Лен=1 ТСВ=495713791 ЦЭР=396694 08:42:25.340517 ХХХ.24.200.ХХХ -> ХХХ.166.98.ХХХ протокол TCP [ПТС ZeroWindowProbeAck] [протокол TCP ZeroWindow] 56371 > макросреда-ФТС [АСК] сл=6 АСК=819134 выиграть=0 Лен=0 ТСВ=396937 ЦЭР=495713791 08:42:30.170698 ХХХ.166.98.ХХХ -> ХХХ.24.200.ХХХ ПТС [ПТС ZeroWindowProbe] макросреда-ФТС > 56371 [АСК] сл=819134 с ACK=6 победит=65535 Лен=1 ТСВ=495714274 ЦЭР=396937 08:42:30.170746 ХХХ.24.200.ХХХ -> ХХХ.166.98.ХХХ протокол TCP [ПТС ZeroWindowProbeAck] [протокол TCP ZeroWindow] 56371 > макросреда-ФТС [АСК] сл=6 АСК=819134 выиграть=0 Лен=0 ТСВ=397420 ЦЭР=495714274 08:42:39.801738 ХХХ.166.98.ХХХ -> ХХХ.24.200.ХХХ ПТС [ПТС ZeroWindowProbe] макросреда-ФТС > 56371 [АСК] сл=819134 с ACK=6 победит=65535 Лен=1 ТСВ=495715237 ЦЭР=397420 08:42:39.801784 ХХХ.24.200.ХХХ -> ХХХ.166.98.ХХХ протокол TCP [ПТС ZeroWindowProbeAck] [протокол TCP ZeroWindow] 56371 > макросреда-ФТС [АСК] сл=6 АСК=819134 выиграть=0 Лен=0 ТСВ=398383 ЦЭР=495715237 08:42:59.032648 ХХХ.166.98.ХХХ -> ХХХ.24.200.ХХХ ПТС [ПТС ZeroWindowProbe] макросреда-ФТС > 56371 [АСК] сл=819134 с ACK=6 победит=65535 Лен=1 ТСВ=495717160 ЦЭР=398383 08:42:59.032696 ХХХ.24.200.ХХХ -> ХХХ.166.98.ХХХ протокол TCP [ПТС ZeroWindowProbeAck] [протокол TCP ZeroWindow] 56371 > макросреда-ФТС [АСК] сл=6 АСК=819134 выиграть=0 Лен=0 ТСВ=400306 ЦЭР=495717160 08:43:00.267721 ХХХ.24.200.ХХХ -> ХХХ.166.98.ХХХ ПТС 56371 > макросреда-ФТС [fин, ПОДТВ] сл=6 АСК=819134 выиграть=0 Лен=0 ТСВ=400430 ЦЭР=495717160 08:43:00.267827 ХХХ.24.200.ХХХ -> ХХХ.166.98.ХХХ ПТС 56371 > макросреда-ФТС [РСТ ПОДТВ] сл=7 АСК=819134 выиграть=65535 Лен=0 ТСВ=400430 ЦЭР=495717160 [!dиода d17]

08:42:20.679200 ХХХ.166.98.ХХХ -> ХХХ.24.200.ХХХ ПТС макросреда-ФТС > 56371 [ПШ, ПОДТВ] сл=817686 с ACK=6 победит=65535 Лен=1448 ТСВ=495713325 ЦЭР=396467

1
задан 1 December 2010 в 21:58

8 ответов

Копирование из ссылки wirehark:

http://wiki.wireshark.org/TCP_Analyze_Sequence_Numbers

TCP ZeroWindow - возникает, когда ресивер объявляет размер окна приема равным нулю. Это эффективно сообщает отправителю прекратить отправку, потому что буфер приемника заполнен. Указывает на проблему с ресурсами в приемнике, так как приложение не извлекает данные из буфера TCP своевременно.

Итак, я предполагаю, что все это ведение журнала - это просто «нормальный» сеанс (TCP) из повешенного приложения (флеш-плагин).

Как вы уже упоминали, журналы если они обнаружены после аварии, так что это не имеет большого значения.

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

1
ответ дан 25 July 2018 в 22:49
  • 1
    На самом деле, я никогда не говорил, что этот свалка TCP был после аварии. Это происходит одновременно с крахом. Очевидно, что сообщение указывает на зависающее приложение (flash), поскольку это проблема. Мой вопрос не в том, что он сбой, но почему и как его исправить. Более того, я хочу знать, что это может быть об одной учетной записи пользователя в одной системе, которая может вызвать проблемы со вспышкой. – Calcipher 2 December 2010 в 23:30

Копирование из ссылки wirehark:

http://wiki.wireshark.org/TCP_Analyze_Sequence_Numbers

TCP ZeroWindow - возникает, когда ресивер объявляет размер окна приема равным нулю. Это эффективно сообщает отправителю прекратить отправку, потому что буфер приемника заполнен. Указывает на проблему с ресурсами в приемнике, так как приложение не извлекает данные из буфера TCP своевременно.

Итак, я предполагаю, что все это ведение журнала - это просто «нормальный» сеанс (TCP) из повешенного приложения (флеш-плагин).

Как вы уже упоминали, журналы если они обнаружены после аварии, так что это не имеет большого значения.

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

1
ответ дан 27 July 2018 в 00:34
  • 1
    На самом деле, я никогда не говорил, что этот свалка TCP был после аварии. Это происходит одновременно с крахом. Очевидно, что сообщение указывает на зависающее приложение (flash), поскольку это проблема. Мой вопрос не в том, что он сбой, но почему и как его исправить. Более того, я хочу знать, что это может быть об одной учетной записи пользователя в одной системе, которая может вызвать проблемы со вспышкой. – Calcipher 2 December 2010 в 23:30

Копирование из ссылки wirehark:

http://wiki.wireshark.org/TCP_Analyze_Sequence_Numbers

TCP ZeroWindow - возникает, когда ресивер объявляет размер окна приема равным нулю. Это эффективно сообщает отправителю прекратить отправку, потому что буфер приемника заполнен. Указывает на проблему с ресурсами в приемнике, так как приложение не извлекает данные из буфера TCP своевременно.

Итак, я предполагаю, что все это ведение журнала - это просто «нормальный» сеанс (TCP) из повешенного приложения (флеш-плагин).

Как вы уже упоминали, журналы если они обнаружены после аварии, так что это не имеет большого значения.

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

1
ответ дан 2 August 2018 в 04:13
  • 1
    На самом деле, я никогда не говорил, что этот свалка TCP был после аварии. Это происходит одновременно с крахом. Очевидно, что сообщение указывает на зависающее приложение (flash), поскольку это проблема. Мой вопрос не в том, что он сбой, но почему и как его исправить. Более того, я хочу знать, что это может быть об одной учетной записи пользователя в одной системе, которая может вызвать проблемы со вспышкой. – Calcipher 2 December 2010 в 23:30

Копирование из ссылки wirehark:

http://wiki.wireshark.org/TCP_Analyze_Sequence_Numbers

TCP ZeroWindow - возникает, когда приемник объявляет размер окна приема равным нулю. Это эффективно сообщает отправителю прекратить отправку, потому что буфер приемника заполнен. Указывает на проблему с ресурсами на получателе, так как приложение не извлекает данные из буфера TCP своевременно.

Итак, я предполагаю, что все это ведение журнала - это просто «нормальный» сеанс ( TCP) из повешенного приложения (флеш-модуль).

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

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

1
ответ дан 4 August 2018 в 20:17

Копирование из ссылки wirehark:

http://wiki.wireshark.org/TCP_Analyze_Sequence_Numbers

TCP ZeroWindow - возникает, когда приемник объявляет размер окна приема равным нулю. Это эффективно сообщает отправителю прекратить отправку, потому что буфер приемника заполнен. Указывает на проблему с ресурсами на получателе, так как приложение не извлекает данные из буфера TCP своевременно.

Итак, я предполагаю, что все это ведение журнала - это просто «нормальный» сеанс ( TCP) из повешенного приложения (флеш-модуль).

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

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

1
ответ дан 6 August 2018 в 04:17

Копирование из ссылки wirehark:

http://wiki.wireshark.org/TCP_Analyze_Sequence_Numbers

TCP ZeroWindow - возникает, когда приемник объявляет размер окна приема равным нулю. Это эффективно сообщает отправителю прекратить отправку, потому что буфер приемника заполнен. Указывает на проблему с ресурсами на получателе, так как приложение не извлекает данные из буфера TCP своевременно.

Итак, я предполагаю, что все это ведение журнала - это просто «нормальный» сеанс ( TCP) из повешенного приложения (флеш-модуль).

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

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

1
ответ дан 7 August 2018 в 22:22

Копирование из ссылки wirehark:

http://wiki.wireshark.org/TCP_Analyze_Sequence_Numbers

TCP ZeroWindow - возникает, когда приемник объявляет размер окна приема равным нулю. Это эффективно сообщает отправителю прекратить отправку, потому что буфер приемника заполнен. Указывает на проблему с ресурсами на получателе, так как приложение не извлекает данные из буфера TCP своевременно.

Итак, я предполагаю, что все это ведение журнала - это просто «нормальный» сеанс ( TCP) из повешенного приложения (флеш-модуль).

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

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

1
ответ дан 10 August 2018 в 10:32

Копирование из ссылки wirehark:

http://wiki.wireshark.org/TCP_Analyze_Sequence_Numbers

TCP ZeroWindow - возникает, когда приемник объявляет размер окна приема равным нулю. Это эффективно сообщает отправителю прекратить отправку, потому что буфер приемника заполнен. Указывает на проблему с ресурсами на получателе, так как приложение не извлекает данные из буфера TCP своевременно.

Итак, я предполагаю, что все это ведение журнала - это просто «нормальный» сеанс ( TCP) из повешенного приложения (флеш-модуль).

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

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

1
ответ дан 13 August 2018 в 16:59
  • 1
    На самом деле, я никогда не говорил, что этот свалка TCP был после аварии. Это происходит одновременно с крахом. Очевидно, что сообщение указывает на зависающее приложение (flash), поскольку это проблема. Мой вопрос не в том, что он сбой, но почему и как его исправить. Более того, я хочу знать, что это может быть об одной учетной записи пользователя в одной системе, которая может вызвать проблемы со вспышкой. – Calcipher 2 December 2010 в 23:30

Другие вопросы по тегам:

Похожие вопросы: