После Playlist.saveWithUpdate потерян порядок треков в плейлисте

[efremych]

Доступа к ПК пока что нет, не могу покопаться, в чем причина…
Пользуюсь SaveWithUpdate уже довольно долго. Не сталкивался с такими проблемами.

Кейс какой.
В одинаковых плейлистах по 520 треков. Удалил трек из сравниваемого плейлиста (вроде бы. мог конечно и добавить, не помню, но это менее вероятно). И после очередного обновления плейлиста треки перемешались в порядке, который объяснить не могу…

Версия библиотеки последняя.

upd. Если правильно посчитал - 100 треков поднялись в начало плейлиста, далее сортировка сохраняется

[Chimildic]

Логически в saveWithUpdate есть два действия:

• удалить то, что есть в плейлисте, но нет в массиве
• добавить то, чего нет в плейлисте, но есть в массиве

Единственный момент влияющий на сортировку это куда добавлять - в начало или конец плейлиста. Параметр toEnd.

Добавление идет пачками по 100 треков, друг за другом последовательно. Пока не придет ответ, следующая пачка не отправится.

Еще заметил на примере лайков с одинаковой датой добавления. В интерфейсе Spotify отображается один порядок, в запросах приходит другой порядок.

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

[efremych]

8 упоминаний locale

Тоже заметил это на картинке, но потом, как видно, всё равно скрипты отрабатывали.

Целиком библиотеку обновляете?

Всё так же точечно :) у меня 11 упоминаний, но 3 - это мои toLocaleDateString

[Chimildic]

Согласно смутному описанию в документации Spotify, если не указывать position при добавлении треков, они пойдут в конец сами. По коду goofy так и происходит. Когда toEnd = true, position не прибавляется к запросу. И остаточного быть не может, поскольку payload создается каждый раз заново в итерациях цикла.

По пути к отправке запроса, флаг toEnd ни что не ломает. Остается предположить, что на стороне Spotify есть баг, который добавляет треки в начало, когда нет position. Хотя в 99,9% случаев добавляется в конец.

Запустил триггер каждую минут с добавлением в конец случайного лайка через saveWithUpdate. Все попадает в конец уже в течении часа.

Я конечно могу и дальше что-то копать в goofy-коде, но нужно больше шагов/фактов/воспроизводимость

[efremych]

Остается предположить, что на стороне Spotify есть баг, который добавляет треки в начало, когда нет position.

Странно, что вообще эта сотня треков решила изменить своё местоположение :) так-то она корректно в конец добавилась, другое дело, что не должна была перемещаться.

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

Думал, может, ответ на поверхности и кто-то уже спрашивал.
А раз, по идее, всё в порядке, буду пристальнее следить за своими плейлистами и караулить ошибки :)

[Chimildic]

Уже сутки триггер добавляет по треку в плейлист. Первый трек не смещается, все идёт в конец. Вероятно в этой схеме нужно что-то ещё.

[efremych]

Вероятно в этой схеме нужно что-то ещё.

В общем, буду наблюдать.

ни в какую не хотел автоматически работать скрипт, который успешно отрабатывал вчера

Вот тут есть шанс хотя бы концы найти.

TypeError: Cannot read property 'name' of undefined
    at compareString(!!!Library:1756:26)
    at [unknown function](!!!Library:1705:24)
    at sortArtist(!!!Library:1702:21)
    at [unknown function](!!!Library:1671:17)
    at repeatArtistCount($My Functions:224:13)
    at mySetDescription($My Functions:32:24)
    at RecentlyPlayed((Recently Played):21:18)

Ругательства, так понимаю, начинаются отсюда. На входе - массив истории прослушивания.
Блок Order.sort я полностью заменил в соответствии с версией библиотеки

Order.sort(copySourceArray, 'artist.name', 'asc');

[Chimildic]

TypeError: Cannot read property 'name' of undefined

По поводу ошибки в сортировки из комментария. Поскольку история прослушиваний это локальный кэш, данные внутри со временем устаревают. В данном случае это касается id исполнителей. По неведомой нам причине, Spotify изменил их у некоторых исполнителей со временем.

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

Когда Spotify сменил id, он продолжает отдавать исполнителей по прошлому значению, но в ответе уже новое id. Поэтому связь оригинального массива и полных объектов обрывается.

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

На данный момент предложу одноразово запустить следующую функцию. Она обновит id основных исполнителей на новые и перезапишет кэш.

function actualize(){
  perform('SpotifyRecentTracks');
  perform('LastfmRecentTracks');
  perform('BothRecentTracks');

  function perform(filename) {
    let tracks = Cache.read(filename);
    let remoteArtists = getCachedTracks(tracks, { artist: {} }).artists;
    let arrayArtists = Object.values(remoteArtists);
    tracks.forEach((t, i) => {
      let id = t.artists[0].id;
      if (!remoteArtists[id]) {
        let artist = arrayArtists.find(a => a.name == t.artists[0].name);
        if (artist) { 
          tracks[i].artists[0].id = artist.id; 
        } else {
          console.log('Не найдено соответствие для', id, t.artists[0].name);
        }
      }
    });
    Cache.write(filename, tracks);
  }
}

[efremych]

Spotify изменил их у некоторых исполнителей со временем

Ого, мда...

У меня такая вот ошибка

	TypeError: Cannot read property 'id' of undefined
    at [unknown function](test3:13:86)
    at perform(test3:10:12)
    at actualize(test3:2:3)

[Chimildic]

Дополнил условием проверки. Возможно дело в локали имен. Тогда соответствие и по имени не найдем.

[efremych]

Возможно дело в локали имен

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

1 несоответствие по итогу. Но дата изменения файла не изменилась.
Заменил у себя order.sort на следующее, посмотрим, не стрельнет ли для обычных плейлистов/треков :) Мне то id в принципе и не нужно. А данный скрипт просто пока сохраню, чтобы был :) Спасибо за разъяснение.

copySourceArray.sort((x, y) => (x.artists[0].name > y.artists[0].name) - (x.artists[0].name < y.artists[0].name));`

[Chimildic]

100 треков поднялись в начало плейлиста, далее сортировка сохраняется

Новых данных не появилось, чтобы отловить проблему?

[efremych]

Новых данных не появилось, чтобы отловить проблему?

Нет. Больше загадочностей не происходило.

Недавно пытался понять, почему отличается порядок треков при сортировке плейлиста в приложении или ПК "свой порядок" и по дате добавления. Но не смог)
Давно замечал, что в обратном порядке любимые треки у меня добавляются в плейлист. Добавил в свою функцию Order.reverse пред сохранением плейлиста, стало чуть лучше, но не до конца.

Т.е., например, в течение дня пролайкал 3 трека. Потом взял эти 3 любимых трека и добавил скриптом в плейлист (например в пустой плейлист) (saveWithUpdate или даже saveWithReplace). Так вот порядок, в котором я лайкал треки не сохраняется в новом плейлисте при сортировке "по дате добавления" - только при сортировке "свой порядок". На примере с тремя треками - порядок первого трека корректен, а два других поменялись местами.

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

[Chimildic]

Треки добавляются пачками по 100. Поэтому у каждой сотни одинаковая дата добавления с точностью до секунды. Может и больше сотни, запросы быстро летают. Поэтому получается странная сортировка по дате. Свой порядок - это то как они в запросе располагались.

[efremych]

Нет. Больше загадочностей не происходило.

Добавляю треки через saveWithReplace.
Сохраняю 365 треков. В плейлист добавляется 630 треков, т.е. 365+(365-100).
Не исключаю, что где-то напортачил - пойду искать где...

[efremych]

Не исключаю, что где-то напортачил

Так и есть, всё норм