Android - Невозможно добавить в очередь RemoteMediaPlayer путем вызова queueInsertItems() несколько раз

Question

Я использую CastCompanionLibrary для добавления элементов в очереди RemoteMediaPlayer по телефону queueInsertItems() из VideoCastManager.java так:

queueInsertItems (unique_items, MediaQueueItem.INVALID_ITEM_ID, customData);

Первые несколько запросов пройти, но после того, как несколько раз, я начинаю получать TransientNetworkDisconnectionException и все последующие запросы возвращают status code 2103 (REPLACED). На этом этапе я больше не могу добавлять элементы в очередь для мультимедиа, пока я не отсоединяюсь и не подключаюсь обратно к литому устройству.

Вот копия моего LogCat:

01-28 00:24:56.750 7185-7185/com.google.sample.cast.myplayer D/ccl_VideoCastManager: [v2.7.1] > queueInsertItems returned. Status code: 2103 
01-28 00:24:56.789 455-469/? I/SurfaceFlinger: id=5534(5) createSurf 0x41449a94 (1x1),1 flag=4, Uoast 
01-28 00:24:56.805 463-1700/? D/PowerManagerService: [api] acquire WakeLock flags=0x2000000a > tag=WindowManager uid=1000 pid=463 
01-28 00:24:56.891 7185-7189/com.google.sample.cast.myplayer D/dalvikvm: GC_CONCURRE> NT freed > 1843K, 28% free 18679K/25856K, paused 4ms+16ms, total 201ms 
01-28 00:24:57.008 28371-12138/? D/CastSocket: [controller-0688 API] IOException encountered. > Tearing down the socket. 
              java.io.IOException: invalid message size (138391) received. 
               at com.google.android.gms.cast.c.o.n(SourceFile:457) 
               at com.google.android.gms.cast.c.o.j(SourceFile:686) 
               at com.google.android.gms.cast.c.v.b(SourceFile:35) 
               at com.google.android.gms.cast.c.w.run(SourceFile:103) 
               at java.lang.Thread.run(Thread.java:856) 
01-28 00:24:57.016 28371-12138/? D/CastSocket: [controller-0688 API] shutdown with reason=2 
01-28 00:24:57.016 28371-28371/? D/CastDeviceController: [controller-0688 API] onDisconnected; > socketError="2 IO Error" 
01-28 00:24:57.023 28371-9680/? D/CastDeviceController: [controller-0688 API] > onSocketDisconnectedInternal: socketError="2 IO Error" 
01-28 00:24:57.023 28371-9680/? I/CastDeviceController: [controller-0688 API] finishDisconnecting; > socketError="2 IO Error", mDisconnectStatusCode=SUCCESS 
01-28 00:24:57.023 28371-9680/? I/CastDeviceController: [controller-0688 API] listener.> onDisconnected(NETWORK_ERR 

Одна вещь, которую я замечаю в моей LogCat что CastSocket API поддерживает выключая с разумом 2 из-за неправильного размера сообщения. Я не уверен, что это значит или почему это происходит. Но может ли кто-нибудь объяснить, что происходит?

Заранее благодарен!

Answer 1

Каждый запрос/api передается с использованием общего сообщения, и каждое сообщение имеет максимальный размер; вы должны предположить, что полезная нагрузка не может выйти за пределы 64k, но имейте в виду, что сообщение состоит из множества вещей, и они легко складываются. Ошибка, которую вы видите о недопустимом размере сообщения, заставляет меня думать, что вы столкнулись с этой проблемой. Попробуйте отправить меньше предметов. Кроме того, обратите внимание, что в текущей структуре недостаточно разбить очередь, скажем, 500 элементов на 20 сообщений с 25 элементами в каждом; хотя вы можете это сделать, вы столкнетесь с проблемами вскоре после того, как все сообщения об обновлениях, отправленные вашим получателем связанным отправителям, также будут соответствовать одному и тому же пределу размера, поэтому они потерпят неудачу, если им нужно будет сообщить об огромном количестве элементов. Возможно, было бы лучше, учитывая текущие ограничения, если бы вы могли каким-то образом управлять очередью таким образом, чтобы в каждый момент времени приемник не содержал слишком много элементов в памяти, тогда как в то же время он знает, как получить больше предметов из вашего (облачного) бэкэнда, когда это необходимо. Вы также можете подумать о том, чтобы сделать некоторое управление на стороне отправителя, чтобы не нажимать слишком много элементов очереди в очередь на приемнике и выгружать некоторые элементы очереди и добавлять некоторые новые, чтобы поддерживать общее количество номеров в памяти низким. Наконец, попробуйте уменьшить информацию для каждого элемента, который вы отправляете получателю, как можно меньше; например, вашему получателю может не понадобиться иметь все поля/метаданные, доступные для элемента, или с учетом структуры пользовательского интерфейса на телевизоре, возможно, он не сможет отобразить, скажем, описание, превышающее 100 символов, поэтому обрезайте информацию до что приемник абсолютно необходим. Затем на стороне отправителя вы можете получить полную информацию/метаданные о каждом элементе из облака непосредственно, поэтому, если второй отправитель присоединяется к стороне, он получает минимальные данные от получателя, а затем заполняет этот пробел, перейдя непосредственно в облако чем полностью полагаться на метаданные, которые получатель может отправить.

Надеюсь, это поможет.