Thanks for the response, maybe you or someone can clarify<br>some of my questions below. I have provided further info.<br><br><div class="gmail_quote">On Thu, Nov 13, 2008 at 1:03 PM, Michael T. Dean <span dir="ltr"><<a href="mailto:mtdean@thirdcontact.com">mtdean@thirdcontact.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d"><br>
</div>OK, by your saying, "when the system deleted the files out of the<br>
'deleted' group," you're implying that you deleted the files to the<br>
Deleted recording group. If you do, the duplicate flag is automatically<br>
changed depending on which delete you select (i.e. is enabled/set to 1<br>
if you say, "Delete," and disabled/set to 0 if you say "Delete and allow<br>
re-record") when you delete the recording to the Deleted recgroup.<br>
(From inside the Deleted recgroup, deleting--not saying, "Delete and<br>
allow re-record"--to remove the file from disk will not flip the switch,<br>
so whatever you chose when deleting it to the Deleted recgroup will stand.)<br>
</blockquote><div><br>yes, this feature was not working. I was using the "Delete" button, NOT "delete<br>and allow re-record", yet, these programs were still being re-recorded, and<br>in the oldrecorded table, the "duplicate" flag for these rows was "0"<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
There /was/ (a /very/ long time ago) a bug in MythWeb that meant that<br>
recordings deleted from MythWeb weren't properly marked for duplicate<br>
detection.</blockquote><div> </div><div>I was using the frontend to delete, NOT mythweb.<br><br>I am running the following version, and I did not have problems<br> with repeat recording until recently:<br>mythtv@dora:~$ mythbackend --version<br>
Source code version : 14657<br>SVN branch : trunk<br>Library API version : 0.21.20070910-2<br>Network Protocol Version: 36<br>Options compiled in:<br> linux release using_oss using_alsa using_arts using_jack using_backend using_dbox2 using_dvb using_firewire using_frontend<br>
using_hdhomerun using_iptv using_ivtv using_joystick_menu using_lirc using_opengl_vsync using_v4l using_x11 using_xrandr using_xv using_xvmc using_xvmcw using_xvmc_vld using_bindings_perl using_opengl using_live <br><br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d"><br>
> After updating the table with "update oldrecorded set duplicate='1';",<br>
> I decided to clean up all the duplicate entries in the table. I had several hundred<br>
> lines which were duplicate title and subtitle,<br>
<br>
</div>As there should be. The recording status for all airings of shows<br>
matching recording rules in the current program listings as well as some<br>
history (7 or 10 days--I don't feel like looking right now) is kept for<br>
reference (i.e. so you can tell why a specific episode didn't record).</blockquote><div> </div><div>The oldrecorded table has its earliest entry with<br>starttime of "2007-08-11 02:15:00". I was talking about cleaning up<br>
lines which were duplicate title and subtitle for shows that had, in fact,<br>recorded, again and again.<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">> so I copied the table to "oldrecorded_test"<br>
> create table oldrecorded_test as select * from oldrecorded;<br>
> and made a delete statement as follows:<br>
> delete from oldrecorded_test T1 where starttime not in<br>
><br>
> select max (starttime) from oldrecorded_test T2 where T2.programid=T1.programid);<br>
> From the contents of oldrecorded_test, this appeared to have worked, so I renamed<br>
> "oldrecorded" to "oldrecorded_back", and renamed "oldrecorded_test" to "oldrecorded".<br>
<br>
</div>Here, you deleted all sorts of important information. BTW, Myth<br>
automatically cleans up this and other tables.</blockquote><div><br>ok, well i was trying to cleanup the hundreds of lines that were in this<br>table from all of the recordings that had been recorded 3 or 4 times,<br>even though I had already watched and deleted them. The query was<br>
supposed to delete only rows for programs that had duplicate<br>programids and to leave the programid with the oldest starttime.<br></div><div> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">
> dropped down under 10 seconds, sometimes as low as 2 seconds.<br>
> My frontend is not hanging like it was, and everything seems better.<br>
><br>
> Some conclusions and questions:<br>
><br>
> I am not a database expert, so is there something wrong with the way I copied the<br>
> table as I listed above?<br>
><br>
<br></div>Erm.... Yeah, you broke Myth's data.</blockquote><div> </div><div>so which data was missing then? if I deleted rows from oldrecorded<br>for programs, which data was mythtv looking for? I still have the damaged<br>
table to examine, it's just been renamed.<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d">> Perhaps some of the other people having issues with slow deletes hanging the frontend<br>
> have done as I did, and have something wrong with the table itself. Is there a way to<br>
> check the oldrecorded table for correct structure,<br>
<br>
</div>It's done automatically once per day by the backend, so just run the<br>
backend.</blockquote><div><br>Restarting the frontend/backend/computer did not fix the problem,<br>and i didn't see errors in the mythbackend log file about missing data.<br>But maybe I wasn't looking in the right place.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d">
> other that the "optimize_mythdb.pl" script?<br>
</div><br>That does other stuff, but still useful. I run it in a daily cron job<br>
at some time in /very/ early morning (when recordings are unlikely).<br>
<div class="Ih2E3d"><br>
> Is there a way to delete and recreate this table as it should be, as a last<br>
> resort for those who have no backup and can't get their frontend to work?<br>
<br>
</div>Basically, the standard answer applies: don't mess with the DB data.<br>
(No matter how much you think you understand the schema/data/constraints<br>
upon that data, Myth understands it much better.) And remember that<br>
Myth cleans up all the old/unnecessary data automatically for you, so no<br>
need to mess with the data.</blockquote><div><br>Yes, but what if your table is already messed up? how would one fix it? <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
Mike<br>
_______________________________________________<br>
mythtv-users mailing list<br>
<a href="mailto:mythtv-users@mythtv.org">mythtv-users@mythtv.org</a><br>
<a href="http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users" target="_blank">http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users</a><br>
</blockquote></div><br>