Мультимедиа.вопросы,проблемы,решения.

Просто 13.3 больше нет ничего. Написано что новейшее

На 13.3 тапнуть надо, тогда ещё версия в скобочках появится.

Аппсолютно верно!

17С54

17С54

Ну, как в том анекдоте, всё, что знал - сказал...

авто разве без навигации ?

Может быть это проблема именно Bosch и RCC?

С 12 тоже перезагружается) откопал тут свой старенький 5s проверить)) обновил его до последней 12.4.4. Перезагружается, только не всегда. За неделю теста-3 раза ,причём не раз в 30 сек,а перезагруз за перезагрузом до update

С 12 тоже перезагружается) откопал тут свой старенький 5s проверить)) обновил его до последней 12.4.4. Перезагружается, только не всегда. За неделю теста-3 раза ,причём не раз в 30 сек,а перезагруз за перезагрузом до update

тогда проблема в ГУ. у меня не перегружается ни на 12 ни на 13

С 12 тоже перезагружается) откопал тут свой старенький 5s проверить)) обновил его до последней 12.4.4. Перезагружается, только не всегда. За неделю теста-3 раза ,причём не раз в 30 сек,а перезагруз за перезагрузом до update

У меня перезагрузки начались когда обновился на 13.3, до этого на других 13... прошивках такого не было. Сейчас сижу на 13.3.1 beta уже где-то недели две, за это время перезагруз был один раз.

тогда проблема в ГУ. у меня не перегружается ни на 12 ни на 13

то что проблема в ГУ это и ежам понятно. iOS шлёт на ГУ какой-то мусор и ГУ падает в перезагруз - не может его переварить. То, что ГУ падает от полученного мусора - это проблема ГУ, а не того кто мусор шлёт.

Надо попробовать сброс до заводских настроек ГУ.  

iOS шлёт на ГУ какой-то мусор

смелое утверждение... и примерно понятно что считать мусором, а что нет?

смелое утверждение... и примерно понятно что считать мусором, а что нет?

и почему на вершн12 этого мусора не слалось, а на 13 попёрло?

Я сам проездил на ГУ без нави с эпплом 12 полгода. Ни одного фейла...

смелое утверждение... и примерно понятно что считать мусором, а что нет?

Почему смелое? 

Это обычное явление. Если, например, сервер на котором крутится этот форум упадёт от огромного количества запросов, чья вина? Сервера или того/тех кто эти запросы отправил?

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

Вот примерно то же самое происходит с ГУ. Ставшая легендой из-за количества багов и глюков прошивка iOS 13 шлёт на ГУ чего-то в энном количестве при соединении как по USB, так и по bluetooth. Это что-то, скорее всего какая-то сетевая техническая информация, которую ГУ переварить не может и обиженно уходит в перегрузку.     

iOS 13 шлёт на ГУ чего-то в энном количестве при соединении как по USB, так и по bluetooth. Это что-то, скорее всего какая-то сетевая техническая информация, которую ГУ переварить не может и обиженно уходит в перегрузку.     

Какие Ваши доказательства (с)

Еще раз, есть какие либо пруфы про мусор. кроме умозаключений?

@kamero,

весьма странное утверждение....

т.е. если Вам в голову кто-то стукнет кулаком, то виновником сотрясения будет ваша голова,

ну именно так и получается по вашей логике  )))

Вообще это в духе времени ...

@chizhik_pyzhik, если кому-то на стройке на голову упадёт кирпич, то виноват будет не кирпич, а тот кто каску не надел.

@koi-sama,

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

Но изначально - вдруг покушение на убийство было ...

@koi-sama, хорошо, другой пример этой логики - в ресторане отравился - сам виноват...

а по поводу кирпича, и НС на стройке (именно на стройке), то тут несколько сложнее, 

так что не нужно передергивать

и при чем тут кирпич? ну если каску пробило или сломало шею? то по твоей логике уже кирпич виновник?

и почему на вершн12 этого мусора не слалось, а на 13 попёрло?

Я сам проездил на ГУ без нави с эпплом 12 полгода. Ни одного фейла...

@chizhik_pyzhik, @igorkzn, фигуральный кирпич на стройке и каска - ожидаемое явление и меры предосторожности против этого явления. Вы не можете сделать так, чтобы кирпич никогда не упал вам на голову - поэтому вы надеваете каску.

Тут то же самое - вы, как разрабочик ГУ, не можете сделать так, чтобы с другой стороны вам никто не прислал мусорные данные, поэтому вы должны предусмотреть проверку данных на корректность и отбросить мусор.

Тут то же самое - вы, как разрабочик ГУ, не можете сделать так, чтобы с другой стороны вам никто не прислал мусорные данные, поэтому вы должны предусмотреть проверку данных на корректность и отбросить мусор.

так, все всегда так хорошо знают, что должны другие )))

а откуда знания про эти "мусорные данные"? может просто эпл изминил что-то в протоколе? и этот протокол просто не совместим с данным ГУ?

скажет производитель изменил штекер(распиновку) микрофона(колонок) и при подключению к голове она не работает, либо разъем ломается, либо по контактам не подходит...

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

и возвращаясь к кирпичу, он будет виноват? а то как-то этот момент ушел в туман...))

ЗЫ

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

@chizhik_pyzhik, в программировании всё работает именно таким образом - вы обрабатываете только корректные данные и принимаете все необходимые меры чтобы некорректные данные не сломали вашу программу. И в первую очередь это касается данных, полученных извне. Другая программа или устройство может работать некорректно, может быть неисправно оборудование, передающее данные, данные могут быть умышленно изменены.

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

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

Если это не была хакерская атака, а был наплыв посетителей, то опять виноват сервер - не справился. Ну, вернее, виноваты сисадмины и программисты, которые настраивали этот сервер. Ну вы поняли.

Нет, не поняли, при чем тут сервер и айтишники.

Если заказчик е*лан и указал в ТЗ 100 посетителей, а пришло внезапно 1000, то есс-но виноваты все кругом, но не заказчик.

Офигеть вы тут словоблудие устроили из разряда лишь бы передёрнуть. Один только koi-sama понял о чём я. 

Короче, сброс ГУ до заводских настроек привёл к тому, что запустился Android Auto, причем с новым интерфейсом и без танцев с бубном. Воткнул USB и оно взлетело, как и должно было. Ехал 3 часа нон-стоп и ни одной перезагрузки, но андроид вроде бы ни у кого этим не грешил. Надо будет с айфоном проверить, но меня терзают смутные сомнения.   

Офигеть вы тут словоблудие устроили из разряда лишь бы передёрнуть. Один только koi-sama понял о чём я. 

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

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

chizhik_pyzhik, в программировании всё работает именно таким образом - вы обрабатываете только корректные данные и принимаете все необходимые меры чтобы некорректные данные не сломали вашу программу.

все не совсем так, обрабатывать приходится все данные, и только корректные принимать, но никогда и нигде нет 100% проверки всего на все, ибо это не возможно,

ну и в конце-то концов, откуда у Вас такая тведая убежденность, что именно кривые данные обрушивают ГУ?

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

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

Данный пример хорошо коррелирует с работой/отказом сервера при наплыве пользователей или ДДОСе (что, с точки зрения сервера, одно и тоже, ...).

Короче, сброс ГУ до заводских настроек привёл к тому, что запустился Android Auto, причем с новым интерфейсом и без танцев с бубном. Воткнул USB и оно взлетело, как и должно было. Ехал 3 часа нон-стоп и ни одной перезагрузки, но андроид вроде бы ни у кого этим не грешил. Надо будет с айфоном проверить, но меня терзают смутные сомнения.   

Так речь вроде шла именно про яблоки? и именно про конкретную версию ОС?

@chizhik_pyzhik, если телефон шлёт кривые данные, то он виноват только в том что шлёт кривые данные. Если ГУ на этих данных валится, то оно виновато в том что валится. Пользователю всё равно, но телефон при этом работать продолжает, а ГУ - нет. Поэтому виновато ГУ.

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

DDoS - это когда запросо настолько много, что с ними не успевает справляться уже железо. То есть у нас на входе условный гигабитный канал, а запросов приходит 10 гигабит. И не важно, что мы всё это можем обработать, 90% запросов будут оставлены без ответа, потому что до нас физически дойти не смогут.

@chizhik_pyzhik, если телефон шлёт кривые данные, то он виноват только в том что шлёт кривые данные. Если ГУ на этих данных валится, то оно виновато в том что валится. Пользователю всё равно, но телефон при этом работать продолжает, а ГУ - нет. Поэтому виновато ГУ.

 

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

 

DDoS - это когда запросо настолько много, что с ними не успевает справляться уже железо. То есть у нас на входе условный гигабитный канал, а запросов приходит 10 гигабит. И не важно, что мы всё это можем обработать, 90% запросов будут оставлены без ответа, потому что до нас физически дойти не смогут.

Это верно, но это не значит, что сервер уходит в перезагрузку. А тут ГУ в перезагрузку уходит.