Hi guys,
Klaus wrote:
> I've already dropped them.
> Besides, these files are just auxiliary internal files for VDR's
> very own purposes. There should normally be no need to edit them at
all.
I'm writing from work (webmail), so sorry if the email format gets
fudged up.
I never really liked the "name all files .vdr" terminology. However,
totally
dropping them is an EQUALLY bad idea, since, unlike Linux, Windows
programs depend on the extension for association. I would like to
…
[View More]propose
using the following:
Video / Audio container files: xyz.ts
Index files: index.vdr
Info files: info.txt
Cutter marks: marks.dat
Resume files: resume.vdr or resume.dat
Klaus says there is no need to edit them (not quite true ;o)), but I
would
like at least to be able to read them easily.
Here are my reasons for asking this:
xyz.ts:
Sometimes it is nice to able to edit or even just watching them
externally.
With an extension that is common to all video editors or players, it
makes
it much easier.
index.vdr:
Index contains no valuable info for external programs and it doesn't
need
editing, so we can leave this or even remove the extension all together.
Info.txt:
The info file esp. is a good thing to have since you can simply copy
the info on a Windows PC (for title or contents) when burn them to a
CD or DVD. It saves time, just being able to copy and paste via
keyboard.
If I have to tell the program to "open with" and associate a programm
EVERY time I burn a video file to DVD it becomes much too time
consuming.
Marks.dat:
To me it has happend a couple of times (esp if vdr runs out of disk
space)
that you are not able to jump forward or backward in a video file or
even
move the placed marks. Being able to edit the marks file or even
deleting
the preset times makes it easy to correct this problem. I can either
place
the marks where I need them (if known) or delete all of them if the
video
file is totally unresponsive.
Resume files: resume.vdr or resume.dat:
I don't use this file, so to me it makes no difference what is done with
the
extension. However, for others, esp. multi-user VDR setups it might be
handy to able to edit these (making the .vdr a better decision to be
able
to differiantiate it from the marks.dat file)
>> any extension at all. If they are in a .rec-directory it should be
>> pretty clear what a file named "index" contains.
Not quite sure who wrote this, but this argument isn't vaild, since
external
editors or programs have no knowledge of VDR's data structure or
hierarchy. Naming (or just deleting ;o)) all the extensions the same
doesn't
change the situation.
kind regards,
Reinhard
[View Less]
Up to now VDR has used names like 001.vdr for its recording files.
While moving to Transport Stream as the recording format, I need to
use a different file name extension, and so was wondering which one
to use. My first idea was *.ts, for "Transport Stream", but when I
point, for instance, Konqueror to such a file, it thinks it is a
"Qt Translation Source". So I was wondering if I should use *.mpg
instead. This one is identified by Konqueror as an MPEG file and
will make it launch a proper …
[View More]player.
What do you think about this?
Is *.mpg also appropriate for h.264 encoded files?
Klaus
[View Less]
> From: Klaus Schmidinger <Klaus.Schmidinger(a)cadsoft.de>
> Up to now VDR has used names like 001.vdr for its recording files.
> While moving to Transport Stream as the recording format, I need to
> use a different file name extension, and so was wondering which one
> to use. My first idea was *.ts, for "Transport Stream", but when I
> point, for instance, Konqueror to such a file, it thinks it is a
> "Qt Translation Source". So I was wondering if I should use *.mpg
…
[View More]> instead. This one is identified by Konqueror as an MPEG file and
> will make it launch a proper player.
>
> What do you think about this?
I am strongly against this.
*.ts may conflict with KDE, but it is a usual ending for transport stream.
Several mpeg-tools can handle this. I think the dreambox is also using *.ts
for its recordings.
*.mpg would give much more problems with applications. A TS is not an
mpeg-file. Applications which can play mpg but not TS may even crash.
Greets,
Martin
[View Less]
vdr-dxr3 0.2.9 is available at https://sourceforge.net/projects/dxr3plugin
2009-01-02: Version 0.2.9
- Update Italian translation (Diego Pierotto)
- Error handling improvements (Ville Skyttä)
- Add SVDRP commands for device release/reopen, audio output settings,
brightness/contrast/saturation (Krzysztof Parma, Ville Skyttä)
- Switch to VDR 1.6's i18n system (Ville Skyttä)
- Drop support for VDR < 1.6.0 (Ville Skyttä)
Hi,
I've encountered a problem with the femon plugin opening
/dev/dvb/adapter0/frontend0 and not closing it. While tracking down a different
issue I wrote a small script that would periodically (every 30 seconds, say)
use svdrp and the femon plugin to grab some information about the current
status of my DVB signal. After some hours of this running I discovered VDR
would have some weird problems, and I've since narrowed it down to the fact
that for whatever reason each loop of my script …
[View More]causes a new opening of
/dev/dvb/adapter0/frontend0, which is never closed (even though I do send the
femon quit command). I can keep track of how many open file handles there are
using "lsof | grep frontend0 | wc", which goes from one open instance at
startup to several hundred after hours of running.
Ultimately, this causes VDR to stop working since the kernel won't allow it to
open any more files beyond a limit. syslog says, as an example
vdr: [14876] ERROR (svdrp.c,126): Too many open files
last message repeated 175 times
Does anyone else see this behaviour, or is it just my setup?
VDR 1.6.0, femon 1.6.5, Debian Testing (mostly), Linux 2.6.28.
Peace,
Brendon
[View Less]