Я тут подумал, а разве нельзя перехватывать просто этот пакет в сети и использовать на компьютере, то есть логиниться ресивер, а пакет пока идет к ресиверу, перехватывается компьютером и используется там. Или там шифрованный канал, например https?
Я читал, что если например купить карточку DRE, то есть ресиверы, в один из которых вставляешь карту, а другие считывают с нее значение, и все ресиверы могут смотреть что хотят в одно время за одну плату.
Я также хотел с шарой, заплатить за один логин, но смотреть одновременно на ресивере и компьютере, то есть ресивер всегда включен и принимает пакеты, и передает в сеть, где когда надо, принимает их компьютер и тоже просматривает каналы.
Хочется выхода hdmi, чего не хватает на стандартных «триколоровских» ресиверах.
Картинки соответствующей на HD каналах.
Возможность вписать исключения для идентов, чтобы каналы не долго переключались.
Я еще посмотрел на ресиверы, как раз встретил GI 7699, GI 8290 и GI 8680 Больше всех понравился, 8680
А какие плюсы GI «не на линуксе» и GI на линуксе, что я не смогу сделать там или там?
В таком варианте, если например 15-ая картинка 200 пикселей, а с 1-ой по 14-ую, 50-100 пикселей, то первый столбец будет больше всех, хотя можно было взять 15-ую картинку и 4-ре картинки самых маленьких.
Да от языка, я думаю, не зависит, select выдает несколько строк, и потом в цикле, обращаясь по очереди к каждой возвращаемой запросом строке, приходится это всё умножать.
Например, если представить массив 100 000 значений, и select запрос, который это всё возвращает. То тут однозначно бы было очень медленно всё. А если бы был этот массив в таблице, то намного быстрее бы это умножилось и сложилось, и MySQL бы не пришлось возвращать такое количество строк.
Но у меня небольшое количество строк, поэтому не принципиально, просто хотел узнать есть ли способ.
Нет, так нет. Буду знать :)
Вариант с созданием таблицы не подходит, таких запросов много и для каждой создавать таблицу, не выгодно в плане скорости.
Созданием этой темы хотел узнать, есть ли способ вставки массива в запрос (одним запросом), о котором я не знаю. Если бы был, то так скорее всего было бы быстрее, чем на стороне приложения.
На ум приходит только, генерация вложенного if select sum(`field`*if(`key`=key1,value1,if(`key`=key2,value2,if(`key`=key3,value3,и т.д.))) from `table` where `key` in (key1, key2, key3)
Но, как понимаете, это не дело.
Да, вероятность ошибки есть, когда в одной половине точки расположены близко к друг другу, но их меньше, чем в другой половинке, разбросанных равномерно по всей, но количеством больше. А что за метод сканирующего окошка, что-то нигде не нашел? Это берем четырехугольник нужного размера, и считаем количество точек в нем, сдвигаем сначала по x +1, до конца, потом y +1 и x снова от начала до конца?
