No longer able to delete recordings from Mythfrontend
Moderator: Forum Moderators
-
- Newcomer
- Posts: 7
- Joined: Sat Mar 25, 2023 11:45 am
Re: No longer able to delete recordings from Mythfrontend
It might be a silly question, but I noticed from the recorded table posted earlier that there's a recordedid primary key - would it be practical to use that instead of the combined key of chanid and starttime (thus avoiding any datetime discrepancies between different SQLs?)
Re: No longer able to delete recordings from Mythfrontend
I am having exactly the same problem, although on 0.31, I am also using Debian 10.
Mariadb updated from 1:10.3.36-0+deb10u2 to 1:10.3.38-0+deb10u1 on 21 February, but I don't think I hit this problem until 13 March, so I am unsure about whether this is caused by an update to Mariadb, but still suspicious.
I have another version of Myth running on a Debian 11 system and have not had any problems.
I've had a look at the logs, but nothing seemed to be having a problem. I'll up the verbosity and post some findings.
Mariadb updated from 1:10.3.36-0+deb10u2 to 1:10.3.38-0+deb10u1 on 21 February, but I don't think I hit this problem until 13 March, so I am unsure about whether this is caused by an update to Mariadb, but still suspicious.
I have another version of Myth running on a Debian 11 system and have not had any problems.
I've had a look at the logs, but nothing seemed to be having a problem. I'll up the verbosity and post some findings.
Re: No longer able to delete recordings from Mythfrontend
@archifishal, not silly at all, I've got that change in my tree (v34-Pre). It works as expected, however,
the (fairly) massive change to use the newer recordedinfo object in place of programinfo isn't complete
and I know of at least one case where data in recordedinfo wasn't complete. I don't know that I'll push
the change.
the (fairly) massive change to use the newer recordedinfo object in place of programinfo isn't complete
and I know of at least one case where data in recordedinfo wasn't complete. I don't know that I'll push
the change.
Re: No longer able to delete recordings from Mythfrontend
Sorry about my previous post which I posted before reading the whole forum. Thanks @dac437 I have downgraded Mariadb and I'm back to being able to delete.
I've been running MythTV for years. This is the first time I've had a problem that has made me come here. Thanks for all the hard work.
I've been running MythTV for years. This is the first time I've had a problem that has made me come here. Thanks for all the hard work.
-
- Newcomer
- Posts: 7
- Joined: Sat Mar 25, 2023 11:45 am
Re: No longer able to delete recordings from Mythfrontend
@CharlesB if you have the time/inclination it might be interesting to compare Mariadb versions on your working Debian 11 box. I was considering upgrading from Debian 10 to 11 myself, so would be good to know if that's an alternative fix to @dac437 's above.
Re: No longer able to delete recordings from Mythfrontend
Did anyone open a bug report with MariaDB?
Re: No longer able to delete recordings from Mythfrontend
I haven't logged anything, but the index + update thing does seem like a bug indeed. I'd expect it to either always fail or always succeed with the implicit cast, regardless of the query type. I didn't see any docs about undefined behaviour either.
Edit: if nobody says they have logged one within the next few days, I'll give it a go...
Edit: if nobody says they have logged one within the next few days, I'll give it a go...
-
- Newcomer
- Posts: 7
- Joined: Sat Mar 25, 2023 11:45 am
Re: No longer able to delete recordings from Mythfrontend
So looking at packages.debian.org, Debian 11 has MariaDB 1:10.5.18-0+deb11u1 vs 1:10.3.38-0+deb10u1 on Debian 10. If @CharlesB is correct saying his Debian 11 box is fine, then it's not broken in 10.5.18 but is broken in 10.3.38.
Re: No longer able to delete recordings from Mythfrontend
@archifishal sorry it took so long to respond.
mariadb-common:
Installed: 1:10.5.18-0+deb11u1
Candidate: 1:10.5.18-0+deb11u1
I guess it's time to upgrade now anyway.
mariadb-common:
Installed: 1:10.5.18-0+deb11u1
Candidate: 1:10.5.18-0+deb11u1
I guess it's time to upgrade now anyway.
Re: No longer able to delete recordings from Mythfrontend
G'day all,
I have this as well...
I had a look at the sql and in the log
Running manually I get:
which just looks plain wrong....
Regardless of the trailing Z recgroupid = 'Deleted'ID looks just wrong to me?
Changing it to
and then after removing the Z
This also fails dur to trailing Z
I have this as well...
I had a look at the sql and in the log
Code: Select all
Apr 6 08:14:01 mythtv mythbackend: mythbackend[639]: I ProcessRequest mythdbcon.cpp:705 (exec) MSqlQuery::exec(DBManager125) UPDATE recorded SET recgroup = 'Deleted', recgroupid = 'Deleted'ID WHERE chanid = '80031' AND starttime = '2023-03-26T16:33:00.000Z' ; <<<< Took 0ms
Apr 6 08:14:01 mythtv mythbackend: mythbackend[639]: I ProcessRequest mythdbcon.cpp:705 (exec) MSqlQuery::exec(DBManager125) UPDATE recorded SET autoexpire = '9999' WHERE chanid = '80031' AND starttime = '2023-03-26T16:33:00.000Z' ; <<<< Took 0ms
Code: Select all
MariaDB [mythconverg]> UPDATE recorded SET recgroup = 'Deleted', recgroupid = 'Deleted'ID WHERE chanid = '80031' AND starttime = '2023-03-26T16:33:00.000Z';
ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near 'ID WHERE chanid = '80031' AND starttime = '2023-03-26T16:33:00.000Z'' at line 1
Regardless of the trailing Z recgroupid = 'Deleted'ID looks just wrong to me?
Changing it to
Code: Select all
MariaDB [mythconverg]> UPDATE recorded SET recgroup = 'Deleted', recgroupid = 3 WHERE chanid = '80031' AND starttime = '2023-03-26T16:33:00.000Z';
Query OK, 0 rows affected (0.001 sec)
Code: Select all
MariaDB [mythconverg]> UPDATE recorded SET recgroup = 'Deleted', recgroupid = 3 WHERE chanid = '80031' AND starttime = '2023-03-26T16:33:00.000';
Query OK, 1 row affected (0.028 sec)
Rows matched: 1 Changed: 1 Warnings: 0
Code: Select all
UPDATE recorded SET autoexpire = '9999' WHERE chanid = '80031' AND starttime = '2023-03-26T16:58:00.000Z'
Re: No longer able to delete recordings from Mythfrontend
@stinga, I believe the trailing Z issue is a red herring. It's more likely that that's just how the message prints with -v database.
(otherwise it would be failing for every query that references a timestamp etc.)
(otherwise it would be failing for every query that references a timestamp etc.)
Re: No longer able to delete recordings from Mythfrontend
Well, it is only a warning....
and I don't think mysql/mariadb support the trailing Z
and I don't think mysql/mariadb support the trailing Z
Re: No longer able to delete recordings from Mythfrontend
I believe every update is failing that has a Z on the end
IE: I can see an update of file size
Yet the filesize is not updated (unless there is an update to set it to zero that I have not seen)
IE: I can see an update of file size
Code: Select all
UPDATE recorded SET filesize = '2917119860' WHERE chanid = '80024' AND starttime = '2023-04-04T16:54:00.000Z'
Code: Select all
MariaDB [mythconverg]> select filesize from recorded where starttime = '2023-04-04T16:54:00.000Z';
+----------+
| filesize |
+----------+
| 0 |
+----------+
Last edited by stinga on Thu Apr 06, 2023 2:11 am, edited 1 time in total.
Re: No longer able to delete recordings from Mythfrontend
Right, the trailing Z isn't valid and it appears that it only exists in the log message, not is the actual query.
There are over 400 instances of UPDATE in lib and programs. I have no information saying that all fail, only
this one and only on 10.3.38 (that we have reports of).
There are over 400 instances of UPDATE in lib and programs. I have no information saying that all fail, only
this one and only on 10.3.38 (that we have reports of).
Re: No longer able to delete recordings from Mythfrontend
@bill6502
I see what you are saying.. but that would seem to make a mockery of the logs if what is being logged is not what is sent to the DB.
Not saying it is right or wrong, just an observation that from a debugging perspective that we can't trust the logs.
I did a tcpdump of port 3306
The trailing Z is sent to the DB.
Bizarrely, that recgroupid = is now OK..... it looks correct.
I see what you are saying.. but that would seem to make a mockery of the logs if what is being logged is not what is sent to the DB.
Not saying it is right or wrong, just an observation that from a debugging perspective that we can't trust the logs.
I did a tcpdump of port 3306
Code: Select all
UPDATE recorded SET recgroup = 'Deleted', recgroupid = 3 WHERE chanid = 80020 AND starttime = '2023-03-12T12:31:00Z'
Bizarrely, that recgroupid = is now OK..... it looks correct.