Mailing List Archive

Vinton Coffman wrote:

> I was editing a show previously recorded and my system locked up
> hard. No useful info in the log files. Anyway, I can't edit this
> file anymore. When I type "e" or "m" to enter edit mode nothing
> happens. It works fine in other files. I guess the database for that
> file is corrupt but I don't know how to fix this. Suggestions please.

take a look at the recorded table, ensure that the 'editing' field is
zero. for some stupid reason though, when you update any field in that
table, the starttime field will also be modified, so you will need to
set that in the same sql statement, something like:

update recorded
set editing = 0, starttime = '20030508133000'
where chanid = 1037 and starttime = '20030508133000';

obviously, change the chanid and starttimes where applicable.

> By the way, is there anything I can do with the files once edited to
> save space. Is this used in transcoding? Is anyone working on fixing
> transcoding?

i am updating transcoding to support removing the cut areas and
re-encoding to a different format/bitrate. its moving along, but i've
still got work to do on handling raw copies (ie. not decoded then
re-encoded).

cheers,

CraigL->Thx();

On Sun, Jun 01, 2003 at 02:27:27PM -0400, Craig Longman wrote:
> Vinton Coffman wrote:
>
> >I was editing a show previously recorded and my system locked up
> >hard. No useful info in the log files. Anyway, I can't edit this
> >file anymore. When I type "e" or "m" to enter edit mode nothing
> >happens. It works fine in other files. I guess the database for that
> >file is corrupt but I don't know how to fix this. Suggestions please.
>
> take a look at the recorded table, ensure that the 'editing' field is
> zero. for some stupid reason though, when you update any field in that
> table, the starttime field will also be modified, so you will need to
> set that in the same sql statement, something like:
>
> update recorded
> set editing = 0, starttime = '20030508133000'
> where chanid = 1037 and starttime = '20030508133000';
>
> obviously, change the chanid and starttimes where applicable.

This is happening because the 'starttime' column is the first column in
the table that is of type 'TIMESTAMP'. MySQL automatically updates the
first TIMESTAMP column for a given row to the current time when a row
changes.

One way to handle this, which provides a bit more info at the cost of a bit
of space, is to always make the first TIMESTAMP column in a table a
lastUpdate column, (or choose your favorite name).

--

Kirby Vandivort Theoretical and Computational Biophysics
Email: kvandivo@ks.uiuc.edu 3051 Beckman Institute
http://www.ks.uiuc.edu/~kvandivo/ University of Illinois
Phone: (217) 244-5711 405 N. Mathews Ave
Fax : (217) 244-6078 Urbana, IL 61801, USA

Kirby Vandivort wrote:

>>take a look at the recorded table, ensure that the 'editing' field is
>>zero. for some stupid reason though, when you update any field in that
>>table, the starttime field will also be modified, so you will need to
>>set that in the same sql statement, something like:
>>
>>update recorded
>>set editing = 0, starttime = '20030508133000'
>>where chanid = 1037 and starttime = '20030508133000';
>>
>>obviously, change the chanid and starttimes where applicable.
>>
>>
>This is happening because the 'starttime' column is the first column in
>the table that is of type 'TIMESTAMP'. MySQL automatically updates the
>first TIMESTAMP column for a given row to the current time when a row
>changes.
>
>
hmmm, i had thought i hadn't seen that happen in oldrecorded, but a
quick test proves me wrong. its kind of strange that the db does this,
makes it kinda tough to have a created timestamp by itself in a table.
i would think that those fields should be changed from timestamp then
to something that can store millisecond times that mysql doesn't see fit
to change on you. oh well, this isn't a database design list, so i
guess i'll stop there.

cheers,

CraigL->Thx();

This issue keeps cropping up, and every time someone resolves to change the
appropriate (not necessarily all) TIMESTAMP fields to DATETIME (not
self-updating) fields. But so far, only one person ever said they had a
patch for it, and I don't think it was submitted for some reason.

-JAC

On Sunday 01 June 2003 02:47 pm, Craig Longman wrote:
>
> hmmm, i had thought i hadn't seen that happen in oldrecorded, but a
> quick test proves me wrong. its kind of strange that the db does this,
> makes it kinda tough to have a created timestamp by itself in a table.
> i would think that those fields should be changed from timestamp then
> to something that can store millisecond times that mysql doesn't see fit
> to change on you. oh well, this isn't a database design list, so i
> guess i'll stop there.
>
> cheers,
>
> CraigL->Thx();

Sorry, I don't know much about sql. Could you post more detailed
instructions on how to fix this?
Thanks