No result with forum search, no similar issue found.
Describe the problem you’re having:
Cannot unsubscribe from the preconfigured feed Tiny Tiny RSS: Forum in all user accounts.
If possible include steps to reproduce the problem:
open preferences
click on “Feeds” tab
open category “Uncategorized” and open context menu for feed Tiny Tiny RSS: Forum
in the dialog “Edit Feed” click on button “Unsubscribe”
confirm dialog “Unsubscribe from Tiny Tiny RSS: Forum?” with click on “OK”
Expected behaviour:
feed should be unsubscribed and removed from the category
Observed behaviour:
feed is not removed from category “Uncategorized”
no error message is shown
tt-rss version (including git commit id):
19.2, commit 5373b2fe0 (shared hoster, cloned from git repo and uploaded by FTP)
Platform (i.e. Linux distro, PHP, PostgreSQL, etc) versions:
PHP Version 7.0.33-0
ubuntu0.16.04.2
MySQL 5.7.25-0
Please provide any additional information below:
in older 18.12 instance unsubscribing this feed works as expected
trying to unsubscribe this feed from the feeds tree in the main window (via context menu, the rest as above) is also not successful. A small overlay dialog “Removing feed…” with a circling progess indicator appears and stays forever in the lower right corner if not cancelled with the closing X.
from the Event Log:
E_ERROR (1)
classes/pref/feeds.php:1619
Uncaught PDOException: SQLSTATE[42S22]: Column not found: 1054 Unknown column ‘created’ in ‘field list’ in /hp/bd/ac/ws/www/ttrss/classes/pref/feeds.php:1619 Stack trace: #0 /hp/bd/ac/ws/www/ttrss/classes/pref/feeds.php(1619): PDOStatement->execute(Array) #1 /hp/bd/ac/ws/www/ttrss/classes/pref/feeds.php(1159): Pref_Feeds::remove_feed(‘1’, 1) #2 /hp/bd/ac/ws/www/ttrss/backend.php(123): Pref_Feeds->remove() #3 {main} thrown
Tried to update the database schema using the URL, result was:
Tiny Tiny RSS database is up to date.
Checked both tables as mentioned in the other posting and there is no column created existent in ttrss_archived_feeds, and in ttrss_version the schema_version is already set to 135.
Tested removing the feed again, still same behaviour and again error log entry.
if you’re sure your database is somehow on version 136 (select * from ttrss_version) but the aforementioned table lacks created field you can either add it manually (see schema/versions/mysql/136.sql) or revert back to schema 135 and let the updater run once more.
anyway, this all has been in that thread @JustAMacUser linked above
As schema 135 was already active, applying the database updater did not suceed, even after cloning the latest commits and synced via FTP.
Went through the above recommendations and the other thread again and again - learning MySQL (and its dirty secrets) was not on my list when I started installing TT-RSS. Therefore it took a little bit longer to figure out what “manually” means in the context of MySQL schemas.
After applying the schema change file 136.sql using MySQLWorkbench, the 19.2 instance (#2 in my counting) decided to run in circles and reported again:
Tiny Tiny RSS database is up to date.
Clicking on the link below the message:
Return to Tiny Tiny RSS
shows the familiar progress bar just flashing and returns to the up to date message. End of story of instance 2 for me, hello instance 3.
From the very same git clone on my local machine I just created a new instance - and was able to delete the feed in question. Problem solved.
Thanks for your assistance.
Reliability of transactions in MySQL still seems to be an issue, but PostgreSQL is unfortunately not available at my shared hoster, and MariaDB not even mentioned in their help system.
I’m glad it’s working now for you. I almost wonder if your first database was not using InnoDB and already in an inconsistent state? If you have it around, it might be good to check, if only for others who may come here with similar issues.
SELECT TABLE_NAME FROM information_schema.TABLES
WHERE TABLE_SCHEMA = 'dbname' AND engine != 'InnoDB';
You are right, every little piece of information regarding this unexpected behaviour should be documented.
Running your query delivered the following:
0 row(s) returned
But I found another point which might have an impact? After creating my former answer I just wanted to check the file size with MySQLWorkbench and discovered different database settings:
Instance 1 (18.12, autocreated databases by Installatron and updated by shared hoster)
Default collation: utf8_general_ci
Default characterset: utf8
Instance 2 (19.2, database created by me using shared hosters web UI, not PHPMyAdmin)
Default collation: latin1_swedish_ci
Default characterset: latin1
Instance 3 (19.2, database created by me using shared hosters web UI, not PHPMyAdmin)
Default collation: latin1_swedish_ci
Default characterset: latin1
I’d write this up as the typical type of thing that can happen when using shared hosting where the admin takes it upon his or herself to keep things running up-to-date.
you need to at least figure out which one of those three databases tt-rss is actually using (see config.php), i would also suggest removing the others to minimize further confusion
(XXXXXX is a user specific ID, therefore I replaced it here)
Shared hoster autocreates new users for new databases on a separated MySQL server with a different URL, and I always create a new database for each installation. My job is to define the shared hoster directory name where to install the instances (1: tinyrss, 2: ttrss, 3: tinytinyrss).
