vdr

vdr@linuxtv.org

3 participants
6742 discussions

[ACM MUM 2023] Call for Doctoral Consortium | Vienna, Austria, December 3-6 2023
by Amal Yassien 08 Aug '23

08 Aug '23

*** CALL FOR DOCTORAL CONSORTIUM - MUM 2023*** *Doctoral Consortium Submission Deadline: 9th of October 2023* * 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=doctoral * * MUM 2023, the 22nd International Conference on Mobile and Ubiquitous Multimedia | Vienna, Austria, December 3-6, 2023 * - MUM 2023, the 22nd International Conference on Mobile and Ubiquitous Multimedia, will be held in Vienna, Austria, December 3rd – 6th. MUM is an interdisciplinary forum for advances in research of mobile and ubiquitous multimedia systems, applications, and services. As part of the Mobile and Ubiquitous Multimedia (MUM) conference, we conduct a joint seminar for PhD students from the various sub-disciplines related to mobile media, ubiquitous computing, and human-computer interaction. The doctoral consortium (DC) will take place on-site on Sunday, Dec 3, 2023, before the main conference. - The DC will be an opportunity for a small group of PhD students to meet and discuss their work with each other and with a panel of experienced researchers in the field, in an informal and interactive setting. We welcome applications from current PhD students studying in any area of relevance to the MUM community. PhD students at any stage of the PhD can apply. Depending on the stage the DC may provide helpful feedback for narrowing down a topic, discussing methodological and technical aspects of the ongoing research, or on the framing and presentation of the results in a thesis. * Submission Guidelines* - To apply for participation in the DC, we ask you to submit a 2-4 pages long paper in Word or LaTeX (using the ACM Primary Article Template) <https://authors.acm.org/proceedings/production-information/taps-production-…>. The paper should describe the context and motivation of your PhD research, the problem and aims that drive your research and your research objectives, hypothesis, and/or questions. It should further describe and explain your (proposed) research approach and methods, and include a discussion of results you may already have. Please also include the context of your PhD, i.e., the university programme in which you conduct your PhD, the status of your PhD, the expected completion date, and any other relevant information on your PhD situation. - Submissions will not be peer-reviewed. We will select students for participation with a view of prioritising those who would likely benefit most. Accepted students will be asked to prepare a presentation on their PhD research, and a poster which will be included in the MUM 2023 poster track. Submissions must be submitted via e-mail to dc.mum2023(a)hcilab.org. For accepted doctoral consortium submissions, the author can select if s/he wants the submission to be included to the conference proceedings. - If you are invited to participate, you must register regularly for the day of the PhD seminar or for the whole conference – or apply to participate free of charge as a student volunteer. Your submission should be 2-4 pages. Please use the template and include the following: - Your name, Advisor(s) name(s), and the university where you are conducting your doctoral work. Submissions should NOT be anonymous. - Current year of study and projected completion date (plus information about the regulations of your PhD program regarding length, any part-time study, etc.) Please address the following questions if applicable for you research: - Which problem do you solve? Why is this problem important? What do you want to find out? - Which steps do you plan to take, and how do you evaluate your results? - Which research papers (not more than 3) are related most to your research? How does your work differ? - What have you found out so far? What’s next? - What’s still missing? Where do you need help? Where would you want to collaborate? *Submissions must be submitted via e-mail to dc.mum2023(a)hcilab.org. <dc.mum2023(a)hcilab.org>* *Important Dates* Submission: October 9th, 2023 Decision Notification: October 17th, 2023 Camera-ready Deadline: November 9th, 2023 Conference Dates: December 3rd, 2023 *Doctoral Consortium Chairs* Albrecht Schmidt, LMU Munich Jasmin Niess, University of Oslo All questions about submissions should be emailed to: dc.mum2023(a)hcilab.org

1 0

[ACM MUM 2023] Call for Workshops and Tutorials | Vienna, Austria, December 3-6 2023
by Amal Yassien 26 Jul '23

26 Jul '23

***CALL FOR WORKSHOPS AND TUTORIALS – MUM 2023*** Deadline for Workshops and Tutorials: August 22nd, 2023 (AoE) ***Workshop proposals will be peer-reviewed and archived in the ACM DL*** * 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=workshops* * MUM 2023, the 22nd International Conference on Mobile and Ubiquitous Multimedia | Vienna, Austria, December 3-6, 2023 * The International Conference on Mobile and Ubiquitous Multimedia (MUM 2023) welcomes proposals for workshops. A MUM Workshop is a forum for attendees with shared interests to *present, discuss, and develop new ideas around a specific theme or domain* related to Mobile and Ubiquitous Multimedia. It is the perfect opportunity for putting the best minds in the field together to build new communities, to explore new ideas, and to develop emerging topics. All *workshops* will take place on Sunday, the first day of the conference (Seminar rooms with equipment will be provided), on the *3rd of December*. Because workshops are meant to encourage ideas exchange, we encourage proposals that go beyond being a mini-conference and that engage participants in hands-on activities and in discussion. We also encourage organisers to open the workshops to conference attendees without a workshop paper, but who would be interested in participating. All *tutorials* will take place on the Sunday before the conference, on the *3rd of December* and you can choose between three formats: 90min, half-day, or full-day. If you are interested in submitting a proposal and wish to discuss your ideas prior to the submission deadline, the workshop chairs welcome any inquiries. You can contact us at *workshoptutorial2023(a)mum-conf.org <workshoptutorial2023(a)mum-conf.org>*. *Important Dates* WORKSHOP AND TUTORIALS SUBMISSION: 22nd of August 2023, AoE WORKSHOP AND TUTORIAL NOTIFICATION: 17th of September 2023, AoE *Recommended Timeline for Internal Workshops* WORKSHOP SUBMISSION: 28th of October 2023, AoE WORKSHOP NOTIFICATION: 11th of November 2023, AoE ** Submission Guidelines ** *WORKSHOPS* - Workshop proposal submissions should be in the *ACM Primary Article Template*. *Submissions should be 6 pages or less* (excluding references) - It should describe your goals for the workshop, how you plan to run the workshop, and any anticipated long-term outcomes that will impact the field. Additionally, include information on how you will publish your call and reach out to potential participants. - Workshop proposal submissions contain an abstract that is less than 150 words long that clearly states the purpose of the workshop. Submissions will be peer reviewed by experts in the field. - Submissions must be submitted via *EasyChair*. Please select Workshops and Tutorials track in *EasyChair*. - Accepted workshop proposals will be included in the conference proceedings published by ACM Press and included in the ACM Digital Library. *TUTORIALS* - Tutorial proposal submissions should be in the *ACM Primary Article Template*. *Submissions should be 6 pages or less* (excluding references), and include the following details: - Title - Topics and objectives of the tutorial and how they are relevant to the MUM community - Description of the tutorial activities - Short biography of the organisers - Proposed tutorial length (90min, half-day, full-day) - Room and material requirements - Maximum number of participants - Tutorial proposal submissions contain an abstract that is less than 150 words long that clearly states the purpose of the tutorial. - Submissions will be juried by the tutorial chairs. Submissions must be submitted via *EasyChair*, please select Workshops and Tutorials track. Accepted tutorial proposals will be included in the conference proceedings published by ACM Press and included in the ACM Digital Library. *BEFORE THE CONFERENCE* *Organisers of the accepted workshops are responsible for the following tasks during the time leading up to the conference* - Announce/disseminate their Workshop: Organisers of an accepted workshop must set up and maintain their own website in which they provide further and updated information about their workshop. The workshop page will be linked to from the official MUM workshop site. - Solicit Submissions from Potential Participants: While some organizers may choose alternate formats, a position paper is generally 2-4 pages long and outlines the submitter’s view on the workshop theme and the reasons for the submitter’s interest in the topic. Proceedings of the workshop's submissions will be in charge of the workshop organizers. Commonly, the workshop's proceedings are included on each workshop's webpage. - Select Participants: Choose participants on the basis of position papers submitted and your goals for the workshop. - Workshop organizers and participants have to register for the conference. - Provide a Participant List: A list of confirmed participants should be sent to the Workshop & Tutorials Chairs (*workshoptutorial2023(a)mum-conf.org <workshoptutorial2023(a)mum-conf.org>*). - Develop a final agenda of workshop activities. - Develop a plan for any follow-up activities. Link to submission system: https://easychair.org/my/conference?conf=mum20230 * Workshop Chairs * Philipp Wintersberger, University of Applied Sciences Upper Austria Thomas Kosch, HU Berlin All questions about submissions should be emailed to: *workshoptutorial2023(a)mum-conf.org* <workshoptutorial2023(a)mum-conf.org>

1 0

Restoring recordings from image
by Kartsa 03 Jul '23

03 Jul '23

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 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

2 1

[ACM MUM 2023] Call for Posters | Vienna, Austria, December 3-6 2023
by Amal Yassien 13 Jun '23

13 Jun '23

*** 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, 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>

1 0

[PATCH 1/4] Fix musl build
by Bernd Kuhls 16 May '23

16 May '23

From: Carlo Landmeter <clandmeter(a)gmail.com> Downloaded from https://git.alpinelinux.org/aports/tree/community/vdr/musl-compat.patch Initial commit: https://git.alpinelinux.org/aports/commit/?id=140248605cee4a0160f80b47ce77a… Signed-off-by: Bernd Kuhls <bernd.kuhls(a)t-online.de> --- i18n.h | 2 +- osd.c | 2 +- thread.c | 4 +++- tools.c | 4 ++-- tools.h | 14 ++++++++++++-- vdr.c | 6 ++++++ 6 files changed, 25 insertions(+), 7 deletions(-) diff --git a/i18n.h b/i18n.h index 03deb6f2..85ce4077 100644 --- a/i18n.h +++ b/i18n.h @@ -46,7 +46,7 @@ const cStringList *I18nLanguages(void); ///< have an actual locale installed. The rest are just dummy entries ///< to allow having three letter language codes for other languages ///< that have no actual locale on this system. -const char *I18nTranslate(const char *s, const char *Plugin = NULL) __attribute_format_arg__(1); +const char *I18nTranslate(const char *s, const char *Plugin = NULL) __attribute__((__format_arg__ (1))); ///< Translates the given string (with optional Plugin context) into ///< the current language. If no translation is available, the original ///< string will be returned. diff --git a/osd.c b/osd.c index 47bda686..0d360c81 100644 --- a/osd.c +++ b/osd.c @@ -12,7 +12,7 @@ #include <stdlib.h> #include <sys/ioctl.h> #include <sys/stat.h> -#include <sys/unistd.h> +#include <unistd.h> #include "device.h" #include "tools.h" diff --git a/thread.c b/thread.c index 93eb8c0d..6e854541 100644 --- a/thread.c +++ b/thread.c @@ -160,7 +160,9 @@ cRwLock::cRwLock(bool PreferWriter) writeLockThreadId = 0; pthread_rwlockattr_t attr; pthread_rwlockattr_init(&attr); +#if defined(__GLIBC__) pthread_rwlockattr_setkind_np(&attr, PreferWriter ? PTHREAD_RWLOCK_PREFER_WRITER_NP : PTHREAD_RWLOCK_PREFER_READER_NP); +#endif pthread_rwlock_init(&rwlock, &attr); } @@ -210,7 +212,7 @@ cMutex::cMutex(void) locked = 0; pthread_mutexattr_t attr; pthread_mutexattr_init(&attr); - pthread_mutexattr_settype(&attr, PTHREAD_MUTEX_ERRORCHECK_NP); + pthread_mutexattr_settype(&attr, PTHREAD_MUTEX_ERRORCHECK); pthread_mutex_init(&mutex, &attr); } diff --git a/tools.c b/tools.c index d04033b1..8b161eec 100644 --- a/tools.c +++ b/tools.c @@ -672,7 +672,7 @@ char *ReadLink(const char *FileName) { if (!FileName) return NULL; - char *TargetName = canonicalize_file_name(FileName); + char *TargetName = realpath(FileName, NULL); if (!TargetName) { if (errno == ENOENT) // file doesn't exist TargetName = strdup(FileName); @@ -1562,7 +1562,7 @@ cReadDir::~cReadDir() struct dirent *cReadDir::Next(void) { if (directory) { -#if !__GLIBC_PREREQ(2, 24) // readdir_r() is deprecated as of GLIBC 2.24 +#if __GLIBC__ while (readdir_r(directory, &u.d, &result) == 0 && result) { #else while ((result = readdir(directory)) != NULL) { diff --git a/tools.h b/tools.h index ff6169ee..60eda179 100644 --- a/tools.h +++ b/tools.h @@ -28,6 +28,16 @@ #include <sys/types.h> #include "thread.h" +#ifndef ACCESSPERMS +# define ACCESSPERMS (S_IRWXU|S_IRWXG|S_IRWXO) /* 0777 */ +#endif +#ifndef ALLPERMS +# define ALLPERMS (S_ISUID|S_ISGID|S_ISVTX|S_IRWXU|S_IRWXG|S_IRWXO)/* 07777 */ +#endif +#ifndef DEFFILEMODE +# define DEFFILEMODE (S_IRUSR|S_IWUSR|S_IRGRP|S_IWGRP|S_IROTH|S_IWOTH)/* 0666*/ +#endif + typedef unsigned char uchar; extern int SysLogLevel; @@ -444,7 +454,7 @@ class cReadDir { private: DIR *directory; struct dirent *result; -#if !__GLIBC_PREREQ(2, 24) // readdir_r() is deprecated as of GLIBC 2.24 +#if __GLIBC__ union { // according to "The GNU C Library Reference Manual" struct dirent d; char b[offsetof(struct dirent, d_name) + NAME_MAX + 1]; @@ -818,7 +828,7 @@ public: data[i] = T(0); size = 0; } - void Sort(__compar_fn_t Compare) + void Sort(int (*Compare)(const void *, const void *)) { qsort(data, size, sizeof(T), Compare); } diff --git a/vdr.c b/vdr.c index 1bdc51ab..0f426e61 100644 --- a/vdr.c +++ b/vdr.c @@ -661,12 +661,18 @@ int main(int argc, char *argv[]) } } else if (Terminal) { +#ifdef __GLIBC__ // Claim new controlling terminal stdin = freopen(Terminal, "r", stdin); stdout = freopen(Terminal, "w", stdout); stderr = freopen(Terminal, "w", stderr); HasStdin = true; tcgetattr(STDIN_FILENO, &savedTm); +#else + // stdin, stdout, stderr are declared FILE const* by musl C library + fprintf(stderr, "Option '-t' is only supported if VDR has been built against glibc.\n"); + return 2; +#endif } // Set user id in case we were started as root: -- 2.39.2

1 3

Wake-on-timer rtcwake experiments on various PC hardware
by Marko Mäkelä 18 Apr '23

18 Apr '23

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 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

3 5

Integartion with systemd and rtcwake
by Marko Mäkelä 15 Apr '23

15 Apr '23

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 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

4 9

Trying to run satip w/ Geniatech EyeTV Netstream 4Sat
by Harald Milz 30 Mar '23

30 Mar '23

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 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

2 2

[PATCH] Add thread safety to cRingBufferLinear
by Patrick Lerda 25 Feb '23

25 Feb '23

Beside preventing crashes with vdr-2.6.3 this is required to get vdr to work properly with the gcc thread sanitizer. --- ringbuffer.c | 18 +++++++++++++++++- ringbuffer.h | 3 +++ 2 files changed, 20 insertions(+), 1 deletion(-) diff --git a/ringbuffer.c b/ringbuffer.c index 902c887..1c24df2 100644 --- a/ringbuffer.c +++ b/ringbuffer.c @@ -210,12 +210,16 @@ int cRingBufferLinear::DataReady(const uchar *Data, int Count) int cRingBufferLinear::Available(void) { + Lock(); int diff = head - tail; - return (diff >= 0) ? diff : Size() + diff - margin; + int available = (diff >= 0) ? diff : Size() + diff - margin; + Unlock(); + return available; } void cRingBufferLinear::Clear(void) { + Lock(); int Head = head; tail = Head; #ifdef DEBUGRINGBUFFERS @@ -224,11 +228,13 @@ void cRingBufferLinear::Clear(void) lastPut = lastGet = -1; #endif maxFill = 0; + Unlock(); EnablePut(); } int cRingBufferLinear::Read(int FileHandle, int Max) { + Lock(); int Tail = tail; int diff = Tail - head; int free = (diff > 0) ? diff - 1 : Size() - head; @@ -259,6 +265,7 @@ int cRingBufferLinear::Read(int FileHandle, int Max) lastHead = head; lastPut = Count; #endif + Unlock(); EnableGet(); if (free == 0) WaitForPut(); @@ -267,6 +274,7 @@ int cRingBufferLinear::Read(int FileHandle, int Max) int cRingBufferLinear::Read(cUnbufferedFile *File, int Max) { + Lock(); int Tail = tail; int diff = Tail - head; int free = (diff > 0) ? diff - 1 : Size() - head; @@ -297,6 +305,7 @@ int cRingBufferLinear::Read(cUnbufferedFile *File, int Max) lastHead = head; lastPut = Count; #endif + Unlock(); EnableGet(); if (free == 0) WaitForPut(); @@ -306,6 +315,7 @@ int cRingBufferLinear::Read(cUnbufferedFile *File, int Max) int cRingBufferLinear::Put(const uchar *Data, int Count) { if (Count > 0) { + Lock(); int Tail = tail; int rest = Size() - head; int diff = Tail - head; @@ -336,6 +346,7 @@ int cRingBufferLinear::Put(const uchar *Data, int Count) lastHead = head; lastPut = Count; #endif + Unlock(); EnableGet(); if (Count == 0) WaitForPut(); @@ -345,6 +356,7 @@ int cRingBufferLinear::Put(const uchar *Data, int Count) uchar *cRingBufferLinear::Get(int &Count) { + Lock(); int Head = head; if (getThreadTid <= 0) getThreadTid = cThread::ThreadId(); @@ -362,14 +374,17 @@ uchar *cRingBufferLinear::Get(int &Count) uchar *p = buffer + tail; if ((cont = DataReady(p, cont)) > 0) { Count = gotten = cont; + Unlock(); return p; } + Unlock(); WaitForGet(); return NULL; } void cRingBufferLinear::Del(int Count) { + Lock(); if (Count > gotten) { esyslog("ERROR: invalid Count in cRingBufferLinear::Del: %d (limited to %d)", Count, gotten); Count = gotten; @@ -387,6 +402,7 @@ void cRingBufferLinear::Del(int Count) lastTail = tail; lastGet = Count; #endif + Unlock(); } // --- cFrame ---------------------------------------------------------------- diff --git a/ringbuffer.h b/ringbuffer.h index 746fc51..cbaa12c 100644 --- a/ringbuffer.h +++ b/ringbuffer.h @@ -58,10 +58,13 @@ public: static void PrintDebugRBL(void); #endif private: + cMutex mutex; int margin, head, tail; int gotten; uchar *buffer; char *description; + void Lock(void) { mutex.Lock(); } + void Unlock(void) { mutex.Unlock(); } protected: virtual int DataReady(const uchar *Data, int Count); ///< By default a ring buffer has data ready as soon as there are at least -- 2.39.1

5 12

[PATCH] Fix cThread related race conditions
by Patrick Lerda 19 Feb '23

19 Feb '23

This change fixes the following issue: ==15457==ERROR: AddressSanitizer: SEGV on unknown address 0x0000000002d0 (pc 0x7fd2f4301710 bp 0x7fd2b5552a30 sp 0x7fd2b5552988 T228) ==15457==The signal is caused by a READ memory access. ==15457==Hint: address points to the zero page. #0 0x7fd2f4301710 in pthread_detach (/lib64/libc.so.6+0x8b710) #1 0xdb4430 in cThread::Start() vdr-2.6.3/thread.c:317 #2 0x7fd2e5ea8fc4 in cIptvStreamer::Open() vdr-2.6.3/PLUGINS/src/iptv/streamer.c:66 #3 0x7fd2e5e1e8c2 in cIptvDevice::OpenDvr() vdr-2.6.3/PLUGINS/src/iptv/device.c:342 #4 0x634903 in cDevice::Action() vdr-2.6.3/device.c:1714 #5 0xdb644a in cThread::StartThread(cThread*) vdr-2.6.3/thread.c:293 #6 0x7fd2f4300729 (/lib64/libc.so.6+0x8a729) #7 0x7fd2f437d0bb (/lib64/libc.so.6+0x1070bb) AddressSanitizer can not provide additional info. SUMMARY: AddressSanitizer: SEGV (/lib64/libc.so.6+0x8b710) in pthread_detach Thread T228 (device 5 receiv) created by T222 (cLiveStreamer s) here: #0 0x7fd2f52d4716 in pthread_create (/usr/lib64/libasan.so.6+0x59716) #1 0xdb437b in cThread::Start() vdr-2.6.3/thread.c:316 #2 0x63a3ad in cDevice::AttachReceiver(cReceiver*) vdr-2.6.3/device.c:1844 #3 0x7fd2e8162c56 in cDummyReceiver::Create(cDevice*) vdr-2.6.3/PLUGINS/src/vnsiserver/videoinput.c:472 #4 0x7fd2e816dbc2 in cVideoInput::Open(cChannel const*, int, cVideoBuffer*) vdr-2.6.3/PLUGINS/src/vnsiserver/videoinput.c:530 #5 0x7fd2e80d78d3 in cLiveStreamer::Action() vdr-2.6.3/PLUGINS/src/vnsiserver/streamer.c:318 #6 0xdb644a in cThread::StartThread(cThread*) vdr-2.6.3/thread.c:293 #7 0x7fd2f4300729 (/lib64/libc.so.6+0x8a729) --- thread.c | 25 +++++++++++++++---------- thread.h | 11 +++++++---- 2 files changed, 22 insertions(+), 14 deletions(-) diff --git a/thread.c b/thread.c index 93eb8c0..21be7a4 100644 --- a/thread.c +++ b/thread.c @@ -312,13 +312,16 @@ bool cThread::Start(void) cCondWait::SleepMs(THREAD_STOP_SLEEP); } if (!active) { - active = running = true; - if (pthread_create(&childTid, NULL, (void *(*) (void *))&StartThread, (void *)this) == 0) { - pthread_detach(childTid); // auto-reap + pthread_t localTid; + running = true; + if (pthread_create(&localTid, NULL, (void *(*) (void *))&StartThread, (void *)this) == 0) { + pthread_detach(localTid); // auto-reap + childTid = localTid; + active = true; } else { LOG_ERROR; - active = running = false; + running = false; return false; } } @@ -339,11 +342,12 @@ bool cThread::Active(void) // performed but no signal is actually sent. // int err; - if ((err = pthread_kill(childTid, 0)) != 0) { + const pthread_t localTid = childTid; + if ((err = pthread_kill(localTid, 0)) != 0) { if (err != ESRCH) LOG_ERROR; - childTid = 0; - active = running = false; + if (active && childTid == localTid) + active = running = false; } else return true; @@ -355,6 +359,7 @@ void cThread::Cancel(int WaitSeconds) { running = false; if (active && WaitSeconds > -1) { + const pthread_t localTid = childTid; if (WaitSeconds > 0) { for (time_t t0 = time(NULL) + WaitSeconds; time(NULL) < t0; ) { if (!Active()) @@ -363,9 +368,9 @@ void cThread::Cancel(int WaitSeconds) } esyslog("ERROR: %s thread %d won't end (waited %d seconds) - canceling it...", description ? description : "", childThreadId, WaitSeconds); } - pthread_cancel(childTid); - childTid = 0; - active = false; + pthread_cancel(localTid); + if (active && childTid == localTid) + active = false; } } diff --git a/thread.h b/thread.h index 16c4bd7..06046ea 100644 --- a/thread.h +++ b/thread.h @@ -13,6 +13,7 @@ #include <pthread.h> #include <stdio.h> #include <sys/types.h> +#include <atomic> typedef pid_t tThreadId; @@ -56,7 +57,7 @@ class cRwLock { private: pthread_rwlock_t rwlock; int locked; - tThreadId writeLockThreadId; + std::atomic<tThreadId> writeLockThreadId; public: cRwLock(bool PreferWriter = false); ~cRwLock(); @@ -79,9 +80,11 @@ public: class cThread { friend class cThreadLock; private: - bool active; - bool running; - pthread_t childTid; + std::atomic_bool active; + std::atomic_bool running; + std::atomic<pthread_t> childTid; + ///< Assume that the content of childTid is valid when the class member + ///< active is set to true and undefined otherwise. tThreadId childThreadId; cMutex mutex; char *description; -- 2.39.1

3 4

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

vdr