You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have come across websites that for some reason use an “@” instead of a dot prior to the file formatting, such as bluesky 12.
When trying to download with a web browser this is automatically corrected when downloading the media, also RSS Guard does it for downloads with default path, so I understand that it is to be expected.
However, it does not happen when configuring RSS Guard to ask for the path on each download (either from the feed or RSS Guard's internal browser), the “@” appears, and it is the user who must notice and fix it each time.
How to reproduce the bug?
Configure RSS Guard to select the download path.
Subscribe to the above feed (2) and download any media.
What was the expected result?
“@” is replaced with a dot.
What actually happened?
No replacement, incorrect and potentially unrecognizable file format :-(
Debug log
time=" 7.162" type="debug" -> CTRL is NOT pressed while sorting articles - sorting with standard mode.
time=" 7.162" type="debug" -> core: Displaying messages from feeds IDs: ''1'' and URLs: 'https://rss-bridge.org/bridge01/?action=display&bridge=BlueskyBridge&data_source=getAuthorFeed&user_id=bsky.app&feed_filter=posts_with_media&format=Atom'.
time=" 7.163" type="debug" -> message-model: Repopulated model, SQL statement is now:
'SELECT Messages.id, Messages.is_read, Messages.is_important, Messages.is_deleted, Messages.is_pdeleted, Messages.feed, Messages.title, Messages.url, Messages.author, Messages.date_created, Messages.contents, Messages.enclosures, Messages.score, Messages.account_id, Messages.custom_id, Messages.custom_hash, Feeds.title, Feeds.is_rtl, CASE WHEN LENGTH(Messages.enclosures) > 10 THEN 'true' ELSE 'false' END AS has_enclosures, (SELECT GROUP_CONCAT(Labels.name) FROM Labels WHERE Messages.labels LIKE '%.' || Labels.custom_id || '.%') as msg_labels, Messages.labels FROM Messages LEFT JOIN Feeds ON Messages.feed = Feeds.custom_id AND Messages.account_id = Feeds.account_id WHERE Feeds.custom_id IN ('1') AND Messages.is_deleted = 0 AND Messages.is_pdeleted = 0 AND Messages.account_id = 1 ORDER BY Messages.date_created DESC;'.
time=" 7.375" type="debug" -> gui: Article list header geometries changed.
time=" 8.639" type="debug" -> gui: Message list got focus with reason 'Qt::MouseFocusReason'.
time=" 8.639" type="debug" -> gui: Current row changed - proxy 'QModelIndex(3,6,0x5f302d2df2a0,MessagesProxyModel(0x5f302d390710, name = MessagesProxyModel))', source 'QModelIndex(3,6,0x0,MessagesModel(0x5f302cad5e80))'.
time=" 8.654" type="debug" -> gui: HTML image resizing took 0 miliseconds.
time=" 8.688" type="debug" -> gui: Hovered link: 'QUrl()'.
time=" 10.496" type="debug" -> gui: Hovered link: 'QUrl(https://cdn.bsky.app/img/feed_fullsize/plain/did:plc:z72i7hdynmk6r22z27h6tvur/bafkreia3hgpr344kcirbug2rnafanc4gzlpurrbrba5ilwpqdz5tk67toi@jpeg)'.
time=" 12.788" type="debug" -> network: Settings of BaseNetworkAccessManager loaded.
time=" 12.797" type="debug" -> gui: Article list header geometries changed.
Operating system and version
OS: Arch Linux
RSS Guard version: 4.8.1 (flatpak)
The text was updated successfully, but these errors were encountered:
Brief description of the issue
I have come across websites that for some reason use an “@” instead of a dot prior to the file formatting, such as bluesky 1 2.
When trying to download with a web browser this is automatically corrected when downloading the media, also RSS Guard does it for downloads with default path, so I understand that it is to be expected.
However, it does not happen when configuring RSS Guard to ask for the path on each download (either from the feed or RSS Guard's internal browser), the “@” appears, and it is the user who must notice and fix it each time.
How to reproduce the bug?
What was the expected result?
“@” is replaced with a dot.
What actually happened?
No replacement, incorrect and potentially unrecognizable file format :-(
Debug log
Operating system and version
The text was updated successfully, but these errors were encountered: