KDE постоянно пытается открыть файл в фоновом режиме

Погрепай в профиле пользователя по нахождению строки «playlist_6_420359.ts» рекурсивно, определи где встречается её упоминание, определи к чему относится файл, в котором ты это найдёшь, отключи.

Ради интереса попробуй сменить локаль, например на en_US.UTF-8, возможно это закладки через окно овертона на тему политики.

Но криво реализованные.

ты уверен что этого файла нет? похоже на создание превьюшки или индексации файла

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

$ rm -rf ~/.cache/*

$ find ~/ -name playlist_6_420359.ts

$ ls  ~/.config/autostart

Судя по логам о пропущеных строках в файле, он всё-таки есть. И это скорее всего не файл на компе а урл, только домен в логе не указали. Ошибок в логе нет, вероятно открывается всё успешно. EXT-INF и прочее - это синтаксис файла .m3u8 с метаданными потокового видео. .ts - это фрагмент этого видео.

Отключи инет на 30 сек и посмотри как изменятся логи.

Разобрался в ситуации, нашел источник проблемы. Им оказался файл .m3u8. Не важно, где он лежит, на рабочем столе, в домашней папке или на примонтированном носителе. Это действительно попытки создания превьюшки. Вот файл, который создает проблемы:

#EXTM3U
#EXT-X-VERSION:3
#EXT-X-TARGETDURATION:6
#EXT-X-MEDIA-SEQUENCE:420357
#EXT-X-PROGRAM-DATE-TIME:2023-01-05T04:27:43.400Z
#EXTINF:6.00000,
/hls2/russia_hd/playlist_6_420357.ts
#EXTINF:6.00000,
/hls2/russia_hd/playlist_6_420358.ts
#EXTINF:0.36000,
/hls2/russia_hd/playlist_6_420359.ts
#EXTINF:5.64000,
/hls2/russia_hd/playlist_6_420360.ts
#EXTINF:6.00000,
/hls2/russia_hd/playlist_6_420361.ts
#EXTINF:6.00000,
/hls2/russia_hd/playlist_6_420362.ts
#EXTINF:6.00000,
/hls2/russia_hd/playlist_6_420363.ts
#EXTINF:6.00000,
/hls2/russia_hd/playlist_6_420364.ts
#EXTINF:6.00000,
/hls2/russia_hd/playlist_6_420365.ts
#EXTINF:6.00000,
/hls2/russia_hd/playlist_6_420366.ts

Судя по сообщениям в логах, плазма ругается на содержимое этого файла, возможно, синтаксис некорректный. Казалось бы, удалить его нафиг и все, проблемы нет. Но все-таки меня волнует вопрос. Даже два.

1. Как отключить генерацию превьюшек для формата m3u8? В настройках дельфина есть выбор форматов, для которых генерить превью, но именно этого формата нет. Я даже снял все галочки, но срач в логах не исчез.
2. Правильно ли вообще то, что плазма как баран уперлась и все время пытается открыть этот файл? Мало ли какой кривой файл появится у пользователя, что же теперь пытаться его открыть до бесконечности? Так можно все логи засрать и батарею посадить, если на мобильном устройстве. По мне, так правильная логика создания превьюшки должна выглядеть так: попытались открыть файл - не получилось - забили и показали стандартную иконку.

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

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

Мало ли какой кривой файл появится у пользователя, что же теперь пытаться его открыть до бесконечности?

Я бы больше беспокоился о том, что там могли быть рабочие урлы и твоё DE бы постоянно к ним обращалось и таким образом их владелец бы знал график включения твоего компа.

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

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

Я бы больше беспокоился о том, что там могли быть рабочие урлы и твоё DE бы постоянно к ним обращалось и таким образом их владелец бы знал график включения твоего компа.

Согласен, еще и лишний трафик, и потенциальная дыра в безопасности. С какой стороны ни посмотри, все плохо

Может, как-то сообщить разрабам кде?

Давайте, каждый демон, сервис и либа

Либа тут скорее всего ffmpeg, и он и правда по дефолту пишет все логи в консоль. А тут его бездумно прилепили с дефолтными настройками и завернули логи в файл.

Может, как-то сообщить разрабам кде?

Может. Но они могут сказать что это плохой файл виноват а не они.

Может. Но они могут сказать что это плохой файл виноват а не они.

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

грипни

grep -R "m3" /usr/share/thumbnailers

и на Mime Type тоже

xdg-mime query filetype твой_m3u8_файл

grep -R "mime_твоего файла" /usr/share/thumbnailers

#например

grep -R "mpegurl" /usr/share/thumbnailers

Это всё понятно и верно, но я писал про то как они будут отмазываться.

грипни

grep -R "m3" /usr/share/thumbnailers

ничего

и на Mime Type тоже

xdg-mime query filetype твой_m3u8_файл

grep -R "mime_твоего файла" /usr/share/thumbnailers

вот

linuxoid@MegaComp:/media/Temp/KDE$ xdg-mime query filetype playlist_6.m3u8 
application/vnd.apple.mpegurl
linuxoid@MegaComp:/media/Temp/KDE$ grep -R "application/vnd.apple.mpegurl" /usr/share/thumbnailers
linuxoid@MegaComp:/media/Temp/KDE$

опять ничего

grep -R «mpegurl» /usr/share/thumbnailers

Если есть vnd.mpegurl и без apple то узнаешь какая программа пытается делать превью твоего файла , скорее всего это ffmpegthumbnailer
Вот в этой программе и убераешь vnd.mpegurl в перечне типов

Решил подождать выхода 24.04, думал авось само рассосётся, может что пофиксили. Обновился. Конечно же, нихрена не пофиксили.

grep -R «mpegurl» /usr/share/thumbnailers

Пробовал, опять же в ответ тишина