Tiny Tiny RSS: Community

Feed "Tiny Tiny RSS: Forum": cannot unsubscribe


#1

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

Thanks for your time and your support in advance.


#2

I’m getting the feeling your database schema is not up to date.

Make sure to update the database schema from the UI (it should ask automatically) or the terminal.

e: You can use this URL format to do it from a web browser:

http://example.com/public.php?op=dbupdate

Read the following and post back:


#3

Thanks for suggesting what to check.

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.


#4

TT-RSS should not give you that message. You’re using a version of TT-RSS that needs schema 136, based on the commit you provided.

You need to make sure your TT-RSS is properly up to date then do the database update. If necessary, you should try to apply the schema manually.


#5

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


#6

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.


#7

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';

Replace dbname with the name of your database.


#8

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

Is this maybe the source of hard to find errors?


#9

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. :man_shrugging:


#10

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


#11
  • Instance 1: ‘DB_USER’, ‘sXXXXXX_2791288’ / DB_NAME’, ‘dbXXXXXXx2791288’
  • Instance 2: ‘DB_USER’, ‘sXXXXXX_2852686’ / ‘DB_NAME’, ‘dbXXXXXXx2852686’
  • Instance 3: ‘DB_USER’, ‘sXXXXXX_2855179’ / DB_NAME’, ‘dbXXXXXXx2855179’

(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).

I will keep the old instances as reference.