Hi
I’ve had VDR running for almost 20 years now. Not continuously of course and occasionally I have updated the system and added more disk and new MB and CPU and so.
My problem is that I had an external disk for saving recordings which did not fit on the internal hard disk and now the external disk has failed. I had XFS on the disk and I have been able to create an image of the disk (probably with big chunks missing) but I have not been able to restore any of the recordings from the image. I …
[View More]have tried with foremost but the problem is the ts files. Foremost does not recognise them out of the box and I would need some header/footer information of the files. But to my understanding the ts files have no special footer which would indicate the ending of a file. Have tried to recognise from current recordings the header and tried with that. Foremost has been able to restore the info files but those are not a big help.
Anyway I was wondering if there are any tools that I could try to restore the recordings. I have tried a lot of different tools (including testdisk and photorec) but have not had any real luck. So any instructions and/or pointers would be appreciated :)
BR
\\Kartsa
[View Less]
*** CALL FOR POSTERS - MUM 2023 ***
Deadline for Posters: 9th of October 2023, AoE
* We apologize if you receive multiple copies of this CfP *
*For the online version of this Call, please visit:
https://mum-conf.org/2023/index.php?web=posters *
* MUM 2023, the 22nd International Conference on Mobile and Ubiquitous
Multimedia | Vienna, Austria, December 3-6, 2023 *
MUM is an interdisciplinary forum for presenting the advances in research
of mobile and ubiquitous multimedia systems, …
[View More]applications, and services. At
MUM, academics and practitioners gather to discuss challenges and
achievements in this field from diverse perspectives, such as *interaction
techniques, user research, system development, software solutions, and
devices.* This year's edition aims to continue the tradition of innovation
and excellence in research established by previous MUM conferences.
The MUM poster track provides an opportunity for researchers and
practitioners to present their *early-stage* and ongoing work on mobile and
ubiquitous multimedia systems, services, interactions and experiences. The
submissions can also describe *preliminary research results* that have not
been fully designed, implemented or tested but show great promise,
summarise several small-scale studies, or introduce novel, challenging and
provoking research directions. Posters provide the opportunity for
researchers and practitioners to present their work to the MUM community in
an informal manner, receive valuable feedback on their research, discuss
potential collaborations and address burning issues.
*Submission Guidelines and List of Topics*
- Topics of interest are those defined for the main paper conference
track. They include, but are not limited to:
- Prototypes and systems tackling relevant technical challenges
- Novel applications for mobile and ubiquitous gaming, learning,
entertainment, social networking, and advertising
- Augmented, mixed, and virtual reality systems and applications
- Case studies, field trials, or user experience evaluations of new
applications and services
- Context-aware and location-based mobile and ubiquitous services
- Metrics and measures for evaluating and testing mobile and ubiquitous
systems
- Privacy and security-related challenges to multimedia systems
- Social implications of mobile and ubiquitous multimedia systems
- Interaction and collaboration with human-centered AI systems
- Tools and development environments for building mobile, wearable, and
ubiquitous multimedia systems
- User interfaces, interaction design, and interaction techniques for
mobile and ubiquitous systems
- Interaction design for automotive and other modes of transportation
- Fabrication and device prototyping
- Poster submissions should be maximum *3 pages long* (excluding
references), and should contain an abstract of maximum 150 words, that
clearly states the poster's contribution to the field. The submission
should be prepared as a PDF file, in single-column format, using either
Word or LaTeX *ACM Primary Article Templates.*
<https://authors.acm.org/proceedings/production-information/taps-production-…>
If
LaTeX is used, single-column mode should be configured by using
*"\documentclass[manuscript,review,anonymous]{acmart}"* as document
class setting.
- Poster papers must be submitted via EasyChair
<https://easychair.org/my/conference?conf=mum20230>. The submissions
will undergo a rigorous review process managed by the poster chairs. The
authors of the accepted submissions will receive instructions about the
format requirements for the poster. They are also expected to bring the
posters to the conference site with them and be present throughout the
posters and demos session of the conference.
- Submissions should be anonymized and will undergo a *double-blind
review process.* They should not have been previously published or be
concurrently under submission elsewhere. Final camera-ready versions of
accepted submissions must be accompanied by a signed copyright form.
Accepted posters will appear in the Proceedings of the International
Conference on Mobile and Ubiquitous Multimedia. The proceedings will be
available in the ACM Digital Library, where they will remain accessible to
thousands of researchers and practitioners worldwide.
- Authors are encouraged to submit an *optional video* of maximum 3
minutes to support their submission, which will be on acceptance published
in the ACM Digital Library (as additional material to the paper). To ensure
videos can be viewed by all reviewers, authors should preferably use 720p
or 1080p resolution, H.264 encoding and the MP4 file format. To accommodate
the upload limits of EasyChair (max. 50mb per file), the bit rate of videos
can be lowered.
Link to Submission System: https://easychair.org/my/conference?conf=mum20230
* Important Dates *
Submission: October 9th, 2023 (AoE)
Notification to authors: November 2nd, 2023
Conference dates: December 3th - December 6th, 2023
* Poster Chairs *
Christina Schneegass, Delft University of Technology
Markus Löchtefeld, Aalborg University
All questions about submissions should be emailed to:
*posters2023(a)mum-conf.org* <papers2023(a)mum-conf.org>
[View Less]
Today, I tested rtcwake on several x86 or x86-64 based computers.
The outcome:
(1) Suspend to RAM (say, "rtcwake -m mem -s 10"):
* Success: Every system.
(2) Wake-on-timer ("rtcwake -m no -s 120 && shutdown -h now" or "rtcwake
-m off -s 120"):
* Success: Lenovo Thinkpad X220 (2012?), and a 5-year-old desktop system
* Fail: IBM Thinkpad X60 (Core Duo from 2006), a HP Zbook from 2016.
(3) Suspend to disk ("rtcwake -m disk -s 120") had no chance of working,
because I never configure …
[View More]any swap partition. I would assume that this
could only work if (2) worked in the first place. On the Debian systems
that I tried, the command would fail as expected. On one Arch Linux
system (Lenovo Thinkpad X220), it forcibly power off the computer and
fail to start automatically; a file system check ran on the manual
power-on.
GNU/Linux is the only operating system on each computer, and apart from
the 32-bit Thinkpad X60, everything boots up via UEFI.
In the BIOS setup of both the Thinkpad X60 and the HP laptop there are
some settings related to powering up on timer. Maybe with something like
nvram-wakeup (which was the only working option for a 2001 Intel Celeron
machine) they could be made to work.
Moral of the story: You can't expect wake-on-timer to "just work" even
on relatively recent hardware. Possibly the chances are better with
desktop or small-form-factor systems than with laptops.
Marko
[View Less]
Some time ago, I created the wiki page
https://www.linuxtv.org/vdrwiki/index.php/Systemd that describes much of
my VDR installation.
On my Raspberry Pi, there is no real-time-clock. My low-tech solution
for waking up VDR for recordings is that I set an alarm on my phone, to
remind me to turn on VDR when needed. Today, I refined that a little by
implementing an idle timeout shutdown when no further recording timers
exist, or when they are in the distant enough future.
I learned that …
[View More]there is a portable Linux tool "rtcwake" that should
support whatever is needed by VDR. It is much simpler than the
"nvram-wakeup" that I used almost 20 years ago. On my Raspberry Pi,
basically any "rtcwake" commands will fail. That provided a good way of
testing the fallback mechanisms of my shutdown script.
I think that it could be useful to include some Systemd integration
scripts in the VDR distribution. My systemd integration consists of 4
parts that are documented in the
https://www.linuxtv.org/vdrwiki/index.php/Systemd wiki page:
* /etc/systemd/system/vdr-keep-alive.sh to control system shutdown
* /var/lib/vdr/vdr-shutdown.sh to handle VDR shutdown (vdr -s)
* some configuration to have a VDR service in Systemd
* optional: additional configuration to have the video directory on USB
storage, to have VDR auto-start when the storage is plugged in.
Because rtcwake does not work on my VDR system, it would be nice to get
some feedback from users of wake-on-timer capable systems. It is
possible that the "rtcwake -m disk -s $2" and "rtcwake -m mem -s $2"
require that "vdr-keep-alive.sh stop" be invoked first and
"vdr-keep-alive.sh start" be invoked once rtcwake successfully returns
(at the wake-up time). It is also possible that the VDR process would
need to be restarted.
Best regards,
Marko
[View Less]
Hi all,
I'm trying to consolidate my stuff a bit and got a 4Sat these days. I'm trying
to run VDR-2.6.0 with the satip plugin connecting to the Satip device. 4
receivers, 2x S19.2E, 2x S13.0E. So far, the LNB ran on a DD Cine PCI-E card
just fine. (but I want to get rid of the server). (Tuner #4 is a Fritzbox
cable receiver).
Initially, all seems to look good:
Mar 29 15:20:55 seneca vdr: [4921] initializing plugin: satip (2.4.1): SAT>IP Geräte
Mar 29 15:20:55 seneca vdr: [4924] SATIP …
[View More]poller thread started (pid=4921, tid=4924, prio=high)
Mar 29 15:20:55 seneca vdr: [4921] cTimeMs: using monotonic clock (resolution is 1 ns)
Mar 29 15:20:55 seneca vdr: [4921] new device number 1 (card index 1)
Mar 29 15:20:55 seneca vdr: [4925] SATIP discover thread started (pid=4921, tid=4925, prio=high)
Mar 29 15:20:55 seneca vdr: [4921] SATIP: Creating device CardIndex=0 DeviceNumber=0 [device 0]
Mar 29 15:20:55 seneca vdr: [4927] SATIP#0 section handler thread started (pid=4921, tid=4927, prio=high)
Mar 29 15:20:55 seneca vdr: [4921] new device number 2 (card index 2)
Mar 29 15:20:55 seneca vdr: [4928] device 1 section handler thread started (pid=4921, tid=4928, prio=low)
Mar 29 15:20:55 seneca vdr: [4921] SATIP: Creating device CardIndex=1 DeviceNumber=1 [device 1]
Mar 29 15:20:55 seneca vdr: [4929] SATIP#1 tuner thread started (pid=4921, tid=4929, prio=high)
Mar 29 15:20:55 seneca vdr: [4930] SATIP#1 section handler thread started (pid=4921, tid=4930, prio=high)
Mar 29 15:20:55 seneca vdr: [4926] SATIP#0 tuner thread started (pid=4921, tid=4926, prio=high)
Mar 29 15:20:55 seneca vdr: [4931] device 2 section handler thread started (pid=4921, tid=4931, prio=low)
Mar 29 15:20:55 seneca vdr: [4921] new device number 3 (card index 3)
Mar 29 15:20:55 seneca vdr: [4921] SATIP: Creating device CardIndex=2 DeviceNumber=2 [device 2]
Mar 29 15:20:55 seneca vdr: [4932] SATIP#2 tuner thread started (pid=4921, tid=4932, prio=high)
Mar 29 15:20:55 seneca vdr: [4921] new device number 4 (card index 4)
Mar 29 15:20:55 seneca vdr: [4934] device 3 section handler thread started (pid=4921, tid=4934, prio=low)
Mar 29 15:20:55 seneca vdr: [4921] SATIP: Creating device CardIndex=3 DeviceNumber=3 [device 3]
Mar 29 15:20:55 seneca vdr: [4935] SATIP#3 tuner thread started (pid=4921, tid=4935, prio=high)
Mar 29 15:20:55 seneca vdr: [4936] SATIP#3 section handler thread started (pid=4921, tid=4936, prio=high)
Mar 29 15:20:55 seneca vdr: [4937] device 4 section handler thread started (pid=4921, tid=4937, prio=low)
Mar 29 15:20:55 seneca vdr: [4921] new device number 5 (card index 5)
Mar 29 15:20:55 seneca vdr: [4921] SATIP: Creating device CardIndex=4 DeviceNumber=4 [device 4]
Mar 29 15:20:55 seneca vdr: [4938] SATIP#4 tuner thread started (pid=4921, tid=4938, prio=high)
Mar 29 15:20:55 seneca vdr: [4939] SATIP#4 section handler thread started (pid=4921, tid=4939, prio=high)
...
Mar 29 15:20:56 seneca vdr: [4921] switching to channel 1 S19.2E-1-1107-17503 (WELT)
Mar 29 15:20:58 seneca vdr: [4957] device 1 receiver thread started (pid=4921, tid=4957, prio=high)
...
Mar 29 15:21:01 seneca vdr: [4928] creating new channel 'SAT.1,;ProSiebenSat.1' on S19.2E transponder 112544 with id 1-1107-17500-0
Mar 29 15:21:01 seneca vdr: [4928] creating new channel 'ProSieben,;ProSiebenSat.1' on S19.2E transponder 112544 with id 1-1107-17501-0
Mar 29 15:21:01 seneca vdr: [4928] creating new channel 'kabel eins,;ProSiebenSat.1' on S19.2E transponder 112544 with id 1-1107-17502-0
Mar 29 15:21:01 seneca vdr: [4928] creating new channel 'SAT.1 Gold,;ProSiebenSat.1' on S19.2E transponder 112544 with id 1-1107-17504-0
... (plus a handful more)
but a minute later,
Mar 29 15:21:59 seneca vdr: [4929] curl_easy_perform() [rtsp.c,369] failed: Timeout was reached (28)
Mar 29 15:21:59 seneca vdr: [4929] SATIP-ERROR: Detected invalid status code 0: rtsp://192.168.20.7/ [device 1]
Mar 29 15:21:59 seneca vdr: [4929] SATIP-ERROR: Pid update failed - retuning [device 1]
Mar 29 15:21:59 seneca vdr: [4932] curl_easy_perform() [rtsp.c,340] failed: Timeout was reached (28)
Mar 29 15:21:59 seneca vdr: [4932] SATIP-ERROR: Detected invalid status code 0: rtsp://192.168.20.7/ [device 2]
Mar 29 15:21:59 seneca vdr: [4935] curl_easy_perform() [rtsp.c,244] failed: Timeout was reached (28)
Mar 29 15:21:59 seneca vdr: [4935] SATIP-ERROR: Detected invalid status code 0: rtsp://192.168.20.7/ [device 3]
Mar 29 15:21:59 seneca vdr: [4935] SATIP-ERROR: Connect failed [device 3]
... and
Mar 29 15:22:03 seneca vdr: [4935] SATIP-ERROR: Detected invalid status code 503: rtsp://192.168.20.7/ [device 3]
Mar 29 15:22:03 seneca vdr: [4935] SATIP-ERROR: Connect failed [device 3]
Mar 29 15:22:04 seneca vdr: [4929] SATIP-ERROR: Detected invalid status code 503: rtsp://192.168.20.7/ [device 1]
Mar 29 15:22:04 seneca vdr: [4929] SATIP-ERROR: Connect failed [device 1]
etc. etc. endlessly, and with netstat I see a lot of attempted rtsp connects:
tcp 0 0 192.168.20.1:42764 192.168.20.7:554 ESTABLISHED 5219/vdr
tcp 0 0 192.168.20.1:53584 192.168.20.7:554 TIME_WAIT -
What might be wrong? Any experience that you can share? Should I return this
device because it is known not to work with the satip plugin? (Not that I
didn't google this before, to no avail.)
I would have preferred an Octopus Net S2, but these devices were withdrawn and
are hard to find.
TIA!
Cheers,
hm
--
We should be careful to get out of an experience only the wisdom that is
in it - and stay there, lest we be like the cat that sits down on a hot
stove-lid. She will never sit down on a hot stove-lid again - and that
is well; but also she will never sit down on a cold one any more.
-- Mark Twain
[View Less]
VDR version 2.6.4 is now available at the official VDR GIT archive
git://git.tvdr.de
You can also get the latest stable version with
git clone --branch stable/2.6 git://git.tvdr.de/vdr.git
or as a tar archive with
http://git.tvdr.de/?p=vdr.git;a=snapshot;h=refs/tags/2.6.4;sf=tbz2
This version fixes a few bugs that came up after the release of version 2.6.3.
The changes since version 2.6.3:
- Updated the Italian OSD texts (thanks to Diego Pierotto).
- Fixed restoring …
[View More]the volume at program start (thanks to Matthias Senzel).
- Fixed symmetry of Begin/EndSegmentTransfer() calls in cEIT::cEIT() (thanks to
Jörg Wendel).
- Added a note to epg.h about not messing with event ids (suggested by Winfried Köhler).
- Added a note to vdr.5 about event ids possibly changing when an event moves from
one table to another.
- Fixed initializing cDvbPlayerControl (was broken in version 2.6.3).
- Reverted 'Fixed a possible crash if an editing process is canceled while the edited
recording is being replayed' (introduced in version 2.6.2), because it caused a
deadlock when moving recordings between volumes.
- Fixed a possible crash if an editing process is canceled while the edited recording
is being replayed (new solution).
- Fixed unnecessary interruption of ongoing recordings if timers avoided the transfer
mode receiver device (thanks to Markus Ehrnsperger).
- Revised support for kernel based LIRC driver (thanks to Marko Mäkelä).
Homepage: http://www.tvdr.de
Facebook: https://www.facebook.com/VideoDiskRecorder
Have fun!
Klaus
[View Less]
Hi,
I would propose the following patch, or some equivalent interface that
would allow cThread::mutex to be used with some cCondVar in derived
classes:
diff --git a/thread.h b/thread.h
index 16c4bd75..cd1d98ab 100644
--- a/thread.h
+++ b/thread.h
@@ -83,7 +83,9 @@ private:
bool running;
pthread_t childTid;
tThreadId childThreadId;
+protected:
cMutex mutex;
+private:
char *description;
bool lowPriority;
static tThreadId mainThreadId;
Because cThread::mutx is …
[View More]declared private and there is no helper member
function, derived classes that wish to use condition variables have to
instantiate a separate cMutex for that. Here is an example from the
rpihddevice plugin that illustrates my point:
diff --git a/omx.c b/omx.c
--- a/omx.c
+++ b/omx.c
@@ -119,17 +119,17 @@ const char* cOmx::errStr(int err)
void cOmx::Action(void)
{
cTimeMs timer;
- m_mutex.Lock();
+ Lock();
while (Running())
{
while (m_portEvents.empty())
- if (m_portEventsAdded.TimedWait(m_mutex, 10))
+ if (!m_portEventsAdded.TimedWait(mutex, 10))
goto timeout;
{
const Event event = m_portEvents.front();
m_portEvents.pop();
- m_mutex.Unlock();
+ Unlock();
switch (event.event)
{
Actually, there is a bug above: the condition for the TimedWait() call
was inverted.
This code illustrates another limitation: There is no way to pass an
absolute time to cCondVar::TimedWait(). On each call, a relative wake-up
time (milliseconds from the current time) will be converted into an
absolute time. If there was a way, we would be able to remove the
"cTimeMs timer" and some related system calls, and have this loop both
wake up every 100 milliseconds, and process events as soon as they
arrive. Here is the VDR part of the patch:
diff --git a/thread.c b/thread.c
index 93eb8c0d..3dcb44d4 100644
--- a/thread.c
+++ b/thread.c
@@ -36,7 +36,7 @@
#define dbglocking(a...)
#endif
-static bool GetAbsTime(struct timespec *Abstime, int MillisecondsFromNow)
+bool cCondVar::GetAbsTime(struct timespec *Abstime, int MillisecondsFromNow)
{
struct timeval now;
if (gettimeofday(&now, NULL) == 0) { // get current time
@@ -81,7 +81,7 @@ bool cCondWait::Wait(int TimeoutMs)
if (!signaled) {
if (TimeoutMs) {
struct timespec abstime;
- if (GetAbsTime(&abstime, TimeoutMs)) {
+ if (cCondVar::GetAbsTime(&abstime, TimeoutMs)) {
while (!signaled) {
if (pthread_cond_timedwait(&cond, &mutex, &abstime) == ETIMEDOUT)
break;
@@ -129,20 +129,27 @@ void cCondVar::Wait(cMutex &Mutex)
}
}
+bool cCondVar::TimedWait(cMutex &Mutex, const timespec &abstime)
+{
+ int err = 0;
+
+ if (int locked = Mutex.locked) {
+ Mutex.locked = 0; // have to clear the locked count here, as pthread_cond_timedwait
+ // does an implicit unlock of the mutex.
+ err = pthread_cond_timedwait(&cond, &Mutex.mutex, &abstime);
+ Mutex.locked = locked;
+ }
+ return err != ETIMEDOUT;
+}
+
bool cCondVar::TimedWait(cMutex &Mutex, int TimeoutMs)
{
bool r = true; // true = condition signaled, false = timeout
if (Mutex.locked) {
struct timespec abstime;
- if (GetAbsTime(&abstime, TimeoutMs)) {
- int locked = Mutex.locked;
- Mutex.locked = 0; // have to clear the locked count here, as pthread_cond_timedwait
- // does an implicit unlock of the mutex.
- if (pthread_cond_timedwait(&cond, &Mutex.mutex, &abstime) == ETIMEDOUT)
- r = false;
- Mutex.locked = locked;
- }
+ if (GetAbsTime(&abstime, TimeoutMs))
+ r = TimedWait(Mutex, abstime);
}
return r;
}
@@ -174,7 +181,7 @@ bool cRwLock::Lock(bool Write, int TimeoutMs)
int Result = 0;
struct timespec abstime;
if (TimeoutMs) {
- if (!GetAbsTime(&abstime, TimeoutMs))
+ if (!cCondVar::GetAbsTime(&abstime, TimeoutMs))
TimeoutMs = 0;
}
if (Write) {
diff --git a/thread.h b/thread.h
index 16c4bd75..04bb4cc5 100644
--- a/thread.h
+++ b/thread.h
@@ -49,7 +49,9 @@ public:
~cCondVar();
void Wait(cMutex &Mutex);
bool TimedWait(cMutex &Mutex, int TimeoutMs);
+ bool TimedWait(cMutex &Mutex, const timespec &abstime);
void Broadcast(void);
+ static bool GetAbsTime(struct timespec *Abstime, int MillisecondsFromNow);
};
class cRwLock {
I did not complete the change to rpihddevice cOmx::Action() yet. We may
be forced to retain two mutexes after all, because OMX_EmptyThisBuffer()
as well as one of the functions called from cOmx::StopAudio() would hang
indefinitely, while holding the cOmx::mutex, blocking the cOmx::Action()
thread. According to
https://forums.raspberrypi.com/viewtopic.php?t=313170 the interface is
largely deprecated. I will try to figure out something.
Best regards,
Marko
[View Less]