Рассинхронизация файла SavedTracks.json и getSavedTracks

[Bedmit]

Обратил внимание, что у меня в массивах с лайками, стали часто попадаться треки без лайков. Стал изучать этот момент и оказалось, что в файле SavedTracks.json сотни не лайкнутых треков. Причем это не просто нелайкнутнатые версии лайкнутых треков, что иногда случается. А действительно, довольно большое количество треков, которых нет в Любимых.
Более того. В самом файле меньше 3 тысяч треков, в то время когда лайков больше 13 тысяч.

В принципе, интересна причина этого.
У есть скрипты снимающие лайки с альбомов и с плейлистов, если они полностью прослушаны. Но лайки с самих треков они не снимают. Есть скрипт добавляющий треки в SavedTracks.json, но только после того как трек лайкнут. На всякий случай я этот момент из скрипта исключил. Больше вроде ни какого автоматического вмешательства ни в файл SavedTracks.json, ни в сами лайки нет. Тем более какого-то удаления из файла.

Я не знаю алгоритм формирования этого файла, но подозреваю, что это должна быть полная копия SavedTracks, с ежедневным обновлением. Т.е. новые лайки добавляются, разлайканые треки удаляются. Судя по всему, у меня эта синхронизация сломалась.

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

Номер: 500
Адрес: https://api.spotify.com/v1/me/tracks?offset=100&limit=50&locale=RU

После этого каждые 2 секунды идет цикл таких сообщений с изменением значения положения трека offset на следующие 50 треков.
Естественно при достижении лимита времени, скрипт полностью останавливается не досчитав до конца.

UPD Все-таки за 300 секунд отработал скрипт с getSavedTracks. По информации из консоли offset=13150, т.е. все лайки. Но количество треков в полученном массиве почему-то всего 3750.

Ну и собственно вопрос - что теперь делать? Каким-то образом получить список лайков, перезалить его в SavedTracks.json? Будет ли при этом соблюдаться история добавления лайков? Будут ли в дальнейшем синхронизировано содержание SavedTracks.json и getSavedTracks?

[Chimildic]

Лайки в файле обновляются каждый день единожды. Если новых лайков за день меньше 50, они просто добавляются к прошлым. Когда новых 50 и больше или сегодня понедельник, файл полностью перезаписывается данными от Source.getSavedTracks.

Если ошибки 500 и паузы в 2 секунды укладываются в лимит выполнения, то в файл запишется не полный объем лайков. То есть запросы отправлены для всех, но успешные ответы только для части. goofy построен так, чтобы игнорировать некоторые ошибки дабы не прерывать скрипты на полпути. Отсюда паузы после ошибок. Иначе нестабильность ответов от Spotify ломает конечную цель - обновление плейлистов.

Учитывая что в файле остались треки, на которых уже нет лайка, файл давненько не перезаписывался. Или Source.getSavedTracks отдает устаревшие данные. Что маловероятно, но не удивился бы. Уже бывало, что в ответах приходит некорректное значение количества треков.

Какую дату покажет этот код? Наверное свежую. Иначе каждый запуск runTasks_ длился бы долго или завершался ошибкой времени выполнения. Плюс надо посмотреть что в логах у runTasks_ в 01:00. Особенно прошлый понедельник.

function caseSyncSavedTracks() {
  let clerkProperty = JSON.parse(UserProperties.getProperties().ClerkTasks)
  console.log('Last success updateSavedTracks:', clerkProperty.updateSavedTracks)
}

Ошибки же 500+ это внутренние проблемы серверов Spotify. С ними ничего не сделаешь. Как писали на их форуме этим летом, подобное может быть связано с большим количеством лайков. Например, могли потерять лимиты. Ведь в плейлист разрешают 10-11 тысяч, а лайки якобы безлимит или какие там правила сегодня, не знаю.

Теорию с лимитами относительно легко проверить. Руками унести пару тысяч нынешних лайков в обычный плейлист, чтобы не потерять. Снять с них лайки Library.deleteFavoriteTracks и вызвать Source.getSavedTracks на тест. Взяв за ориентир где нибудь 9-9.5 тысяч оставшихся лайков.

Поэтому поразбираться с runTasks_ можно, но если Source.getSavedTracks не дает треков то и синхронизация поломается.

[Bedmit]

Код показал Last success updateSavedTracks: 2023-10-01T22:32:25.704Z В логах runTasks_ ведет себя стандартно.
В 1:14 2.10.23 (этот понедельник) скрипт не отработал. Те самые ошибки каждые 2 секунды и в итоге "время ожидания истекло".
Добраться в логе до предыдущего понедельника уже не могу. Или не знаю как.

[Bedmit]

Скрипя сердцем проверил теорию о превышении лимита в 10 т. треков. Потому что хоть лайки и можно потом восстановить, такой ценный ресурс как время их добавления, будет утерян. Но выхода нет, вопрос надо как-то решать.

Сперва удалил последние 3,5 т. треков, естественно сохранив их в файл.

function DeleteSavedTracks() {
let Saved = Source.getSavedTracks(3500);
  Cache.write('SavedBackup.json', Saved);
  Library.deleteFavoriteTracks(Saved);
}

После этого удалось через Source.getSavedTracks получить все 9,5 т. оставшихся лайков.
На сколько я понимаю, результат говорит о том, что со стороны Spotify ограничений в лайках и отдаче их через API нет. Проблема исключительно со стороны Google Apps Script, с его ограничением обработки одного скрипта на 6 минут. Он просто не успевает посчитать такое количество треков. Не знаю, возможно сам скрипт можно как-то оптимизировать, например делать паузу в 1 секунду. Но все равно когда-то можно упереться в потолок. Если на глазок, то это 50 * 1 * 60 * 6 = 18 т. треков.

Теперь соответственно вопросы:

1. Как принудительно восстановить файл SavedTracks.json?
2. Как потом добавить в него же удаленные 3,5 т. лайков?
3. Что теперь в принципе делать с синхронизацией, если я верну лайки обратно?

[Bedmit]

Таки да, получилось!!! Все 9695 треков до копейки, без единой ошибки. Причем довольно бодро посчитал.
Сейчас попробую вернуть лайки до 13 к и посчитать с ними.

[Bedmit]

Добавил. Посчитало все 13195 треков. По дороге выдавало сообщения об ошибках, но считало с довольно большими и неравномерными шагами. Тем не менее в результате ни одного трека не утеряно!
Не знаю, как будет при большем количестве лайков и вообще, как будет себя вести в дальнейшем. Но сейчас это отличный результат.
Как всегда большое спасибо за поиск решение очередной проблемы!

Я полагаю, мне сейчас есть смысл запустить восстановление SavedTracks.json?

    tracks = Source.getSavedTracks();
    Cache.compressTracks(tracks);
    Cache.write('SavedTracks.json', tracks);

[Chimildic]

Единственное я не знаю насколько существенно это влияет на остальные скрипты с точки зрения времени выполнения. Например там, где собираются треки из больших плейлистов (внутри тот же принцип, пачками). В первых версиях goofy было последовательно друг за другом, а с появлением REQUESTS_IN_ROW резко ускорилось. И до сих пор это единственный способ параллельности. Google не хочет добавлять асинхронность в GAS.

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

запустить восстановление SavedTracks.json

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

[Bedmit]

Все восстановил. Даже все плейлисты пообновлял. Теперь сразу видно, что суть скриптов выполнена верно. Особых изменений при обработке скриптов по времени, не заметил. Буду наблюдать, появятся ли они в дальнейшем.
Еще раз спасибо!

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

[Bedmit]

Дополнительно, в подтверждении работы автоматики.

В этот понедельник runTasks_ отработал updateSavedTracks полностью. Информация об ошибках с неравномерным шагом есть, скрипт уложился почти в 2 минуты и посчитал все лайки. Хотя, думаю количество ошибок и время выполнения может быть разным.

Поэкспериментировал сейчас немного с REQUESTS_IN_ROW, со значениями 5, 10 и 20. Время выполнения:
5 - 77 сек
10 - 90 сек
20 - 109 сек (100 треков не досчиталось)
Информация об ошибках при любом значении.

В итоге решил оставить 10. За эти дни, влияния изменения этого параметра на работу других скриптов, не заметил.