Udo Richter wrote:
==4652== Invalid free() / delete / delete[]
==4652==at 0x1B904B04: free (vg_replace_malloc.c:152)
==4652==by 0x8103F5F: cTimer::operator=(cTimer const) (timers.c:108)
==4652==by 0x80FE349: cSVDRP::CmdMODT(char const*) (svdrp.c:1136)
==4652==by 0x81015C1: cSVDRP
Klaus Schmidinger wrote:
It's probably best to implement an actual copy-constructor.
Please try the attached patch, which contains both changes.
Attached is the correct version.
Thats the better fix of course, and may fix this in case some plugin did
the same mistake. (couldn't find one in
martin wrote:
just to let you know: the patch you attached here, did not solve the
problem! My VDR crashed again.
Just a few minutes too late...
The patch had another bug that re-introduced the original problem once
again. The new copy constructor did not initialize the aux pointer, and
the
Klaus Schmidinger wrote:
That'll teach me not to write code when I'm on my way out to the
Biergarten... ;-)
Next time, do it afterwards. Afterwards, code is much more 'fluently'. ;)
Cheers,
Udo
___
vdr mailing list
vdr@linuxtv.org
[EMAIL PROTECTED] wrote:
I'm the happy user of xineliboutput 1.0.0pre3.
I'd like to know if it's possible for other rtp clients to play
the multicast stream. (while xine+xineliboutput is playing it)
In fact i'd like to be able to use vlc to transcode/re-stream it.
I've tried, and was
Klaus Schmidinger wrote:
So how shall we distinguish between cReceivers that do actual
recordings and such that just receive, e.g., teletext data?
Or those that receive a radio channel for streaming it to
a remote client? Where's the limit?
Is there a way to predict whether receiving a channel
Jukka Palko wrote:
I have been running vdr 1.4 version with rather good success for some
time now, but now all of a sudden I have started getting almost
continuous restarting of vdr.
Aug 23 09:31:11 sempron vdr: [16318] ERROR: video data stream broken
Cards in machine are:
# lspci -v -s 0a.0
Jukka Palko wrote:
I doublechecked things on the host a while back and looks like the cause
is clock adjustment. :) After disabling the adjustment from
transmissions, the continuous restarting ended. Propably ain't got the
priviledges set up properly. ;)
Aug 23 10:00:32 sempron vdr: [19692]
Klaus Schmidinger wrote:
@Martin: any news on this? With recent drivers and firmware it should be
possible to record and watch even the high-bandwidth channels like ZDF
on a FF card.
Question is, how recent. I'm just running a recording on ARD.
vdr-1.4.1-5, DVB driver of kernel 2.6.16.19,
Klaus Schmidinger wrote:
Udo Richter wrote:
Lots of transfer buffer overflows and sluggish OSD, because
VDR used the primary FF card for recording, while the secondary budget
card is idle. System is back to normal if I switch to another channel.
Just tested it by recording ARD from
Anssi Hannula wrote:
Consider this scenario:
- user watches channel 1, transponder 1, via FF
- recording starts for channel 1, transponder 1, via FF
add here:
- live view is interrupted as FF switches to transfer mode
- recording starts for channel 2, transponder 2, via budget
The primary
Jörn Reder wrote:
Hmm, it's not that easy because it ignores the original intention of
this thread.
Not really. The side effect that osdteletext will force recordings on
the FF card on the same transponder was caused by the change in 1.4.1-2,
that was some time before your post. Its going
VDR User wrote:
Klaus, any particular reason you're not releasing the TODO list?
Probably to keep expectations down. If feature X is on the todo list,
then it might be implemented next week. Or next month. Or next year. Or
in 5 years. Or never.
But people will for sure ask every week 'when
e9hack wrote:
after applying the patch, I get many entries (30 per second) in the syslog:
Aug 6 23:20:23 very-new-darkstar vdr: [11415] ERROR (svdrp.c,84): Address
already in use
The svdrp server port (default 2001) is in use by another program, in
other words, there's another VDR instance
401 - 414 of 414 matches
Mail list logo
