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

❯ Предисловие

Ремонт и реставрация гаджетов с помоек — это особое хобби, которое несмотря на всю не-гигиеничность процесса, доставляет нереальное количество дофамина. Представьте себе ситуацию: у вас в юности не было телефона Sony Ericsson с поддержкой Java-игр, вы со слюнками смотрели на аппараты своих приятелей, а когда телефон попадал вам в руки, чтобы вы могли пройти гоночку в Asphalt'е или уровень в Bobby Carrot'е — вы буквально сдували с него пылинки, чтобы не повредить это чудо инженерной мысли!

И вот прошли долгие годы: у вас были самые разные бюджетные телефоны, со школьных времен вы научились паять, изучать схемотехнику устройств, диагностировать аппаратные и программные неисправности, и даже реверсить прошивки. Вы больше не 12-летний пацаненок по имени Бодя, который мечтает о «Сонерике» или хотя-бы Samsung C3010 с поддержкой Java, а взрослый дядя Богдан, который с годами только укрепил свою любовь к гаджетам...

Поэтому я совершенно не брезгую подбирать интересные устройства со свалок или выкупать их из утиля. Меня часто в комментариях называли барахольщиком, Плюшкиным или просто «поехавшим», а я ведь всего-лишь хочу дать новую жизнь гаджетам прошлых лет, о которых я и сам когда-то мечтал. Например, год назад я решил выкупить с десяток устройств из утиля в Китае, дабы попытаться их восстановить и найти им новое применение. Одним из гаджетов стала легендарная Nokia N-Gage Classic, которую мне удалось восстановить после воды и вмешательства другого мастера в рамках отдельной статьи:

В процессе поиска необычных устройств, я наткнулся на очень интересный гаджет родом из 2009 года. В те годы, в Китае был повсеместно распространен стандарт связи CDMA и в страну серым импортом поступали тысячи японских операторских телефонов с отвязанным симлоком. А уж как мы знаем, на японском рынке всегда хватало диковинных и необычных устройств. Например, там до сих пор остаются популярными раскладушки с большими дисплеями, кнопочные смартфоны на Android и просто забавные телефоны с интересным дизайном:

Но тот гаджет, что я нашёл — был просто уникален и имя ему Sharp IS01. Смартфон продавался по смешной цене в 500 рублей, однако продавец, который явно занимался перепродажей телефонов из утиля, сразу уточнил, что устройство не подаёт признаков жизни. Я всё же решил рискнуть и заказал его с помощью подписчиков Романа и Андрея, за что им огромное спасибо!

Однако IS01 я купил не только из-за необычного дизайна. Дело в том, что по сути это уникальный для своих лет смартфон, который открывается как ноутбук и подразумевает постоянную работу с QWERTY-клавиатурой. И она здесь была реализована на высшем уровне: клавиши большие, ход кнопок как у полноценного ноутбука, а для навигации предусмотрен отдельный трекбол в верхней части устройства. И это при том, что у него есть резистивный тачскрин!

При этом с точки зрения габаритов и эргономики, IS-01 держит золотую середину между классическим коммуникатором и нетбуком: он лёгкий, помещается в карман джинс и на нём удобно печатать даже на ходу. Не стоит также забывать и про «бронированность» IS01: благодаря его форм-фактору и толщине корпуса, шанс разбить дисплей или тачскрин приближается к нулю. Для тех времен, когда емкостные тачскрины отказывали даже после небольшого падения на линолеум — это было важно!

Не менее интересной была и программная часть устройства. Гаджет был построен на базе самой свежей операционной системы Android 1.5 с кастомной оболочкой и даже собственным SDK для разработки приложений, специально адаптированных для IS-01. Пожалуй, это была одна из первых, если не первая «вендорская» оболочка: в те годы чаще всего ставили либо AOSP, либо обычный Android с Google-сервисами:

И всё же класс Android-ноутбуков не то чтобы был очень редким. За всё время существования системы выходило множество устройств, которые так или иначе пытались заменить ноутбук: Toshiba AC100, китайские безымянные лэптопы на чипсетах WonderMedia и Allwinner, Asus TransformerPad и даже устройства от небольших стартапов по типу Dion. Но только IS01 и Dion смогли объединить удобство смартфона, коммуникатора и ноутбука в одно устройство...

Что-же касается моего IS01, то с ним получилась сложная история...

❯ Разбираем

После прибытия смартфона, я сразу же подкинул его к ЛБП и попытался включить. На моё удивление, смартфон начал потреблять от 100 до 200мА, при этом судя по графику потребления, инициализация явно проходила нормально. Однако ни подсветки, ни изображения на дисплее не было.

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

Брак? «Гарантийка»? Или просто шлейф отошёл из коннектора? Я решил разобрать смартфон и постараться продиагностировать причину неисправности. Начал я с дисплейной части, однако вот незадача: вся «фронтальная» часть устройства (то есть рамка дисплея и топкейс) буквально приклеена к шасси и представляет из себя обычную пластиковую «наклейку». И вот это уже большой минус к ремонтопригодности: при отклеивании она легко деформируется и при повторной установке есть немалый шанс оставить очень неприятные зазоры:

Сам конструктив устройства показался мне несколько знакомым, в QWERTY-смартфонах Sony Ericsson используется такая же проклейка для некоторых частей клавиатуры, вот только сама клавиатура там не деформируется. После снятия задней части корпуса на крышке смартфона, всё стало предельно ясным...

Наш пациент — водолаз. При этом судя по интенсивной коррозии, искупался он в море и за годы простоя коррозия «съела» всю дисплейную плату. При этом сам коннектор шлейфа был визуально в норме и часть пинов с него свободно звонились до межслойных переходов, которые, к слову, здесь вообще не покрыты маской. Однако уже здесь мы видим одну из фишек IS01: Sharp разработала кастомный дисплейный модуль специально для этого смартфона. На нём мы видим отдельный драйвер подсветки, предположительно чип для формирования BIAS-напряжения матрицы и линии тачскрина. Похоже здесь дисплей настолько кастомный, что для его управления используется отдельный чип-контроллер (по аналогии с дисплеями Sony, которым требовался отдельный контроллер на плате) и если он вышел из строя — неудивительно что дисплей отказывается стартовать...

Но эта фишка скорее негативная с точки зрения ремонтопригодности: никакой информации о чипах на плате и уж тем более схемы нет. Поэтому я провел тестовые замеры выхода с драйвера подсветки, постарался восстановить очевидные дорожки и не получив результата смирился с тем, что без референсного «донора» IS01 восстановить не выйдет...

Но увидев такой необычный конструктив устройства, мне захотелось подробнее изучить его платформу, а заодно и осмотреть основную плату. Она оказалась полностью исправной и никаких следов коррозии на ней не было, да и с шлейфом всё было нормально. К слову, шлейф здесь используется «неубиваемый» (куда более прочный, чем классический FPC), состоящий из отдельных жилок: такое решение было характерным только для флагманских устройств по типу Nokia E90, Toshiba Portege G910 и некоторых других моделей подобного форм-фактора.

С фронтальной части платы скрывалась микросхема флэш-памяти от Toshiba объёмом в 4ГБ, предположительно RF-фронтэнд и усилитель мощности, а также контроллер питания Qualcomm PM7540, который включает в себя логику для зарядки литиевых аккумуляторов, набор LDO и DC-DC преобразователей, которые формируют основные шины питания на плате, а также включает в себя конечный автомат, описывающий текущее состояние устройства.

Рядом с микросхемой памяти расположился некий чип IXA297A, который разработан самой SHARP. И вот здесь то и закрадываются подозрения в том, что это тот самый контроллер дисплея или некий кастомный мультиконтроллер по аналогии с обычными ноутбуками. Информации о нём я не нашёл.

С обратной стороны платы расположилось сердце устройства — чипсет Qualcomm QSD8650, являющийся одним из самых первых процессоров линейки Snapdragon под индексом S1. Будучи представленным в 2008 году, QSD8650 базировался на собственном ядре Qualcomm Scorpio (модифицированный Cortex), работающем на частоте 1ГГц, поддерживал набор инструкций ARMv7 и имел FPU, а за 3D-ускорение отвечал GPU Adreno 200, который представлял из себя переименованный ATi Imageon Z430. При этом Z430'ый — наследник микроархитектуры GPU Xenos в Xbox 360 и по сути был одним из первых массовых мобильных 3D-ускорителей с поддержкой OpenGLES 2.0 и соответственно шейдерного пайплайна. До этого, мобильные GPU в основном были Fixed Function.

С верхней части скрывается дополнительный контроллер питания TPS65023 разработки компании Texas Instruments. Этот КП отвечает исключительно за формирование дополнительных шин питания на плате, но каких конкретно — я с наскоку так и не понял.

Довольно интересно реализована радиочасть: почти весь RF-тракт вынесен на отдельную плату и припаян к основной методом поверхностного монтажа. Увы, даже здесь используются кастомные чипы, о которых вообще нет никакой информации.

❯ Заключение

Такой вот интересный гаджет выпустила компания Sharp в далёком 2009 году. И с одной стороны — это шедевр технологической мысли, в который инженеры вложили немало сил и денег с точки зрения R&D. Но с другой... нестандартные платформы уже сами по себе куда менее ремонтопригодны, чем классические платформы, унаследованные от референсных плат. И порой задаешься вопросом: а может глобализация и унификация таких компонентов это все таки хорошо?

Увы, но восстановить IS01 у меня не вышло. И дело не в навыках, а банальном отсутствии хоть какой-то документации на устройство. Копать буквально некуда и без как минимум референсного рабочего устройства здесь не разобраться...

Если вам понравилась статья и вы хотите меня поддержать, у меня есть Boosty, а также виджет на Пикабу ниже. А ещё мне можно отправить какое-нибудь интересное железо: устройства на WinCE/WinMobile, китайские кнопочники, китайские подделки на iPhone/Samsung из начала 2010-х, ретро-ПК железо - всё это я очень люблю :) Всем огромное спасибо!

2. Отправьте ссылку боту t.me/yandex2spotify_bot

3. Получите ссылку на готовый плейлист в Spotify и добавьте его к себе

Профит!

Работает также через веб: yandex2spotify.chipichui.space

Скорость импорта:

• 1 000 ~ 30 сек

Важно:

• Не все треки есть в Spotify

• Иногда названия могут совпадать не идеально (в среднем менее ~8%)

• Порядок треков сохраняется

Сервис работает на бесплатной основе для любого количества плейлистов/треков

А теперь начнем

Увидев "крутой" новый дизайн ЯндексМузыки, а так же, что управление на сайте с клавиатуры:

L - перемотка трека вперед

Space - пауза/play

ВКЛЮЧАЯ управление с модификаторов клавиш по типу fn + ►► и т.д., не работают от слова совсем, не говоря уже о цензуре, неимении определенной части треков в наличии, плюс все прочие минусы — было принято решение ретироваться на Spotify

Очевидно, идем в яндекс и ищем варианты переноса и находим

1. Пост на DTF где необходимо сначала пойти в один сервис и спарсить треки плейлиста в текстовый файл, затем пойти в другой сервис которому необходимо скормить этот текстовый файл

2. Soundiiz - где не работает авторизация в яндекс аккаунт, сообщение об ошибке пересылает нас на пост поддержки, которая в свою очередь ссылается на GitGub Discussion где описано получение токена авторизации из яндекс музыки

3. Прочие сервисы с аналогичными проблемами

У меня возник вопрос: неужели в 2026 году нет БЕСПЛАТНОГО сервиса который переносит плейлисты из Яндекс Музыки в Spotify в один клик без танцев с бубном?

Я в это реально не верил, но все поиски были тщетны...

Поэтому я взялся написать сервис, который предоставляет такую возможность - бесплатно импортировать любое количество треков/плейлистов В ОДИН КЛИК

Проблема 1: Яндекс не предоставляет официальный публичный API

Решение:

Проблема решается использованием НЕофициального API из публичного репозитория

Окей, мы спарсили плейлист с яндекса, теперь нам нужно импортировать треки на Spotify

Буквально пару строк кода, думал я...

Изначально, нужно сказать как происходит взаимодействие с Spotify API:

Вам нужно перейти на Developer Dashboard и создать свое приложение, вы получите client_id и client_secret посредством этого вы будете общаться со Spotify

Приложения имеют два mode

1. Developer mode

2. Extended quota mode

Developer mode имеет скудные лимиты на API, плюс авторизация доступна только тем пользователям, которые ПРЕЖДЕВРЕМЕННО были внесены в белый список приложения

Список ограничен на 25 пользователей

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

НО, для того что бы получить Extended quota mode нужно соответствовать некоторым требованиям

Требования к реализации:

1. Устоявшееся юридическое лицо (юридически зарегистрированное предприятие или организация)

2. В настоящее время ведется работа над действующим и запущенным сервисом.

3. Поддержание минимального количества активных пользователей (не менее 250 тыс. активных пользователей в месяц).

4. Доступность на ключевых рынках Spotify

5. Коммерческая жизнеспособность

6. Соблюдение условий

Очевидно, мой пет проект не претендует ни на одно требование

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

Таким образом, импортировать плейлист в 1 000 треков - это МИНИМУМ 1 000 запросов на поиск, не говоря уже о retry и добавлении треков в плейлист

Из этого вытекает следующий скоуп проблем

Проблема 2: Недоступность Extended quota mode

Проблема 2.1: Список пользователей ограничен до 25

Мало того, что список ограничен до 25, нам нужно ПРЕЖДЕВРЕМЕННО внести пользователя в белый список для возможной авторизации пользователя на сервисе

Решение:

Было принято решение НЕ добавлять возможность авторизации через Spotify для клиента

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

Пользователь просто будет добавлять импортированный плейлист к себе

Плейлист останется у пользователя, даже если будет удален на основном аккаунте, так же, пользователь может воспроизводить любые действия с плейлистом: обновить название, удалить треки, добавить треки и так далее

Плейлист становится собственностью пользователя

Проблема 2.2: Ничтожные лимиты API

Самая главная проблема

Spotify НИГДЕ не указывает конкретные цифры по лимитам, поэтому это было выявлено методом тыка и получением бана в 90 000 секунд

Rate Limit: ~ <10 req/s

Получив примерное ограничение по лимитам, мы можем оптимистично прикинуть сколько у нас займет времени на импорт плейлиста в 2 000 треков

2000 / 10 = 200 сек = 3.3 минуты

Добавление треков в плейлист происходит батчами по 100 треков, это нам на руку

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

Итоговое время будет ближе к 4 минутам

Такое меня, конечно же, не устраивает

Решение:

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

Таким образом, мы имеем пул клиентов, расширяя тем самым пропускную способность

Итоговый Rate Limit: ~ <40 req/s для 3-4 клиентов

Почему не 100 аккаунтов?

Я думал об этом, но пока я думал, у Spotify вынесли фулл дамп базы на 256млн записей, включая 86млн аудиофайлов - поэтому Spotify уже неделю не дает возможности создавать приложения

Если посчитать так же оптимистично, то на поиск 2 000 треков у нас уйдет

2000 / 40 = 50 сек

Отлично, теперь поиск будет супер реактивным

думал я...

Проблема 2.3: Привязка Rate Limit

В интернете я нашел инфу от интузиастов на подобии меня, что лимиты привязаны к приложению + пользователю

То есть: если у пользователя несколько приложений - то его лимит все равно остается на уровне <10 req/s

Логично предположить, что это решается созданимем нескольких аккаунтов с собственными приложениями, но даже таким образом лимит остался на уровне <10 req/s

Проблема была в том, что привязка лимитов происходила следующим образом:

10 req/s = пользователь + client_id + ip

Решение:

В текущее время, почти у всех есть собственный VPS с поднятым VLESS, таковым являюсь и я

Было принято решение арендовать range ipv6, благо он стоит копейки ~ 0,031292 руб/день

Далее

1. Создать несколько inbounds типа socks на разные порты

2. Смапить порты с ipv6

3. Профит!

Теперь, осталось только при инициализации пула Spotify клиентов выдать им необходимые прокси

Эпилог

Резюмируем:

Итого у нас есть:

1. Взаимодействие с API яндекс музыки посредством публичного НЕофициального репозитория

2. Пулл из нескольких клиентов Spotify

3. Range ipv6 для каждого клиента из пула для увеличения пропускной способности

4. +/- оптимизированный код

Теперь, можно поговорить о боевом тестировании

Исходные данные:

• Было: 2633 трека за 280 сек

• Стало: 2633 трека за 75 сек

Посчитаем:

• Скорость раньше: 2633 / 280 ≈ 9.4 трека/сек

• Скорость сейчас: 2633 / 75 ≈ 35.1 трека/сек

То есть:

• Ускорение: 35.1 / 9.4 ≈ 3.7×

• Сокращение времени: 280 → 75 сек = –73%

У Яндекса есть ограничение на количество треков в плейлисте - 10 000

Если прикинуть линейно, то импорт такого плейлиста будет занимать ~5 минут

Таким образом, у нас есть сервис, который БЕСПЛАТНО импортирует публичный плейлист с яндекс музыки В ОДИН КЛИК за секунды

Считаю, получилось довольно не плохо

Стек:

Backend Stack

Framework: ASP.NET Core 8.0 (C#)

Architecture: RESTful API + Background Workers

Dependency Injection: Autofac

API Integration:

Spotify Web API (SpotifyAPI-NET)

Yandex Music API

Telegram Bot API

Authentication: OAuth 2.0 (Authorization Code Flow с auto-refresh токенов)

Caching & Stats: Redis 7.4

Security: Cloudflare Turnstile (bot protection)

Proxy: SOCKS5 прокси-пул из нескольких инстансов для обхода rate limits Spotify API

Infrastructure & DevOps

Containerization: Docker + Docker Compose

CI/CD: GitHub Actions

Reverse Proxy: Traefik (автоматические HTTPS сертификаты от Let's Encrypt)

Hosting: Self-hosted VPS

Monitoring: Structured logging, Redis-based metrics

Архитектурные фичи

Client Pooling: Динамический пул из нескольких Spotify клиентов с least-loaded балансировкой

Rate Limiting: Exponential backoff + автоматический retry на 429/503

Background Processing: Очередь импорта с concurrent обработкой (до 12 параллельных search-запросов)

Streaming Import: Поиск треков и добавление в плейлист батчами по 100 шт. (без ожидания завершения всех поисков)

Dual Interface: Web UI + Telegram bot с единой очередью импорта

Graceful Degradation: Автовосстановление соединений с Redis и Spotify API

p.s.#1: будет обновляться по мере необходимости, возможно в дальнейшем будет

• улучшенный кастомный матчинг треков

• кеш запросов

• с вероятностью <1% поиск треков будет переписан под слитую БД Spotify, в таком случает импорт 10к треков будет составлять 10 секунд

p.s.#2 могут быть непредвиденные ошибки и баги - если найдете можете отписать в комменты

p.s.#3 если у кого то есть плейлист в 10к треков для теста - отпишите в комменты