vdr April 2017

vdr@linuxtv.org

4 participants
7 discussions

VDR ISDB-T support
by Christian Rodriguez 14 Sep '18

14 Sep '18

Hello everyone! I'm from Argentina, and up to last month I've been using VDR 1.7.262 with an ISDB-T USB adapter. It works really good, but the last week I've been trying to upgrade to VDR 2.2 and I've found a problem with ISDB-T cards: they are not supported. As I'm really interested in using VDR, I was digging inside the code and found a partial solution for this problem: as ISDBT is the same as DVBT, I've changed the way delivery system is queried. My changes are applied in a cloned repo at github: https://github.com/chrodriguez/vdr/commit/dadbca57c2dc55c1c53b4fa8f68b56728… That's the only change I've made. Now I can enjoy my fresh upgraded VDR installation!! I think a better refactor should be made, but for now it's working perfectly deployed as a docker container: https://registry.hub.docker.com/u/chrodriguez/vdr Thanks for this wonderfull project! -- Lic. Christian A. Rodriguez @car_unlp

4 7

VDR locking up
by VDR User 29 Dec '17

29 Dec '17

Occasionally my signal drops out (haven't looked into it yet), and it causes VDR to completely freeze and become defunct/zombie. That locks up the drivers and the only way to resolve it is by rebooting. No core file gets created. Does anyone know how to prevent the lock-up in the first place? Could it be some kind of leak from the looping (see log clip below)? Here's a clip of the log when it happens. You can see how the log gets filled with the same repeating lines until it crashes. 2016.Oct.28|12:08:55 video: slow down video, duping frame 2016.Oct.28|12:08:55 video: decoder buffer empty, duping frame (5656/167423) 7 v-buf 2016.Oct.28|12:09:29 video: slow down video, duping frame 2016.Oct.28|12:16:09 [1297] [softhddev]Clear: 2016.Oct.28|12:16:09 [1297] ERROR: TS packet not accepted in Transfer Mode 2016.Oct.28|12:16:09 audio/alsa: using device 'default' 2016.Oct.28|12:16:09 audio/alsa: start delay 336ms 2016.Oct.28|12:16:09 [1297] [softhddev]Clear: 2016.Oct.28|12:16:10 audio/alsa: using device 'default' 2016.Oct.28|12:16:10 [1297] ERROR: TS packet not accepted in Transfer Mode 2016.Oct.28|12:16:10 audio/alsa: start delay 336ms 2016.Oct.28|12:16:10 [1297] [softhddev]Clear: 2016.Oct.28|12:16:10 audio/alsa: using device 'default' 2016.Oct.28|12:16:10 [1297] ERROR: TS packet not accepted in Transfer Mode 2016.Oct.28|12:16:10 audio/alsa: start delay 336ms 2016.Oct.28|12:16:10 [1297] [softhddev]Clear: 2016.Oct.28|12:16:10 audio/alsa: using device 'default' 2016.Oct.28|12:16:10 [1297] ERROR: TS packet not accepted in Transfer Mode 2016.Oct.28|12:16:10 audio/alsa: start delay 336ms 2016.Oct.28|12:16:10 [1297] [softhddev]Clear: 2016.Oct.28|12:16:10 audio/alsa: using device 'default' 2016.Oct.28|12:16:10 [1297] ERROR: TS packet not accepted in Transfer Mode 2016.Oct.28|12:16:10 audio/alsa: start delay 336ms 2016.Oct.28|12:16:10 [1297] [softhddev]Clear: 2016.Oct.28|12:16:10 audio/alsa: using device 'default' 2016.Oct.28|12:16:10 [1297] ERROR: TS packet not accepted in Transfer Mode 2016.Oct.28|12:16:10 audio/alsa: start delay 336ms 2016.Oct.28|12:16:10 [1297] [softhddev]Clear: 2016.Oct.28|12:16:10 audio/alsa: using device 'default' 2016.Oct.28|12:16:10 [1297] ERROR: TS packet not accepted in Transfer Mode 2016.Oct.28|12:16:11 audio/alsa: start delay 336ms 2016.Oct.28|12:16:11 [1297] [softhddev]Clear: 2016.Oct.28|12:16:11 audio/alsa: using device 'default' 2016.Oct.28|12:16:11 [1297] ERROR: TS packet not accepted in Transfer Mode 2016.Oct.28|12:16:11 audio/alsa: start delay 336ms 2016.Oct.28|12:16:11 [1297] [softhddev]Clear: 2016.Oct.28|12:16:11 audio/alsa: using device 'default' 2016.Oct.28|12:16:11 [1297] ERROR: TS packet not accepted in Transfer Mode 2016.Oct.28|12:16:11 audio/alsa: start delay 336ms 2016.Oct.28|12:16:11 [1297] [softhddev]Clear: 2016.Oct.28|12:16:11 audio/alsa: using device 'default' 2016.Oct.28|12:16:11 [1297] ERROR: TS packet not accepted in Transfer Mode 2016.Oct.28|12:16:11 audio/alsa: start delay 336ms 2016.Oct.28|12:16:11 [1297] [softhddev]Clear: 2016.Oct.28|12:16:11 audio/alsa: using device 'default' 2016.Oct.28|12:16:11 [1297] ERROR: TS packet not accepted in Transfer Mode 2016.Oct.28|12:16:11 audio/alsa: start delay 336ms 2016.Oct.28|12:16:11 [1297] [softhddev]Clear: 2016.Oct.28|12:16:11 audio/alsa: using device 'default' 2016.Oct.28|12:16:11 [1297] ERROR: TS packet not accepted in Transfer Mode 2016.Oct.28|12:16:11 audio/alsa: start delay 336ms 2016.Oct.28|12:16:11 [1297] [softhddev]Clear: 2016.Oct.28|12:16:12 audio/alsa: using device 'default' 2016.Oct.28|12:16:12 [1297] ERROR: TS packet not accepted in Transfer Mode 2016.Oct.28|12:16:12 audio/alsa: start delay 336ms 2016.Oct.28|12:16:12 [1297] [softhddev]Clear: 2016.Oct.28|12:16:12 audio/alsa: using device 'default' 2016.Oct.28|12:16:12 [1297] ERROR: TS packet not accepted in Transfer Mode 2016.Oct.28|12:16:12 audio/alsa: start delay 336ms 2016.Oct.28|12:16:12 [1297] [softhddev]Clear: 2016.Oct.28|12:16:12 audio/alsa: using device 'default' 2016.Oct.28|12:16:12 [1297] ERROR: TS packet not accepted in Transfer Mode 2016.Oct.28|12:16:12 audio/alsa: start delay 336ms 2016.Oct.28|12:16:12 [1297] [softhddev]Clear: 2016.Oct.28|12:16:12 audio/alsa: using device 'default' 2016.Oct.28|12:16:12 [1297] ERROR: TS packet not accepted in Transfer Mode 2016.Oct.28|12:16:12 audio/alsa: start delay 336ms 2016.Oct.28|12:16:12 [1297] [softhddev]Clear: 2016.Oct.28|12:16:12 audio/alsa: using device 'default' 2016.Oct.28|12:16:12 [1297] ERROR: TS packet not accepted in Transfer Mode 2016.Oct.28|12:16:12 audio/alsa: start delay 336ms 2016.Oct.28|12:16:12 [1297] [softhddev]Clear: 2016.Oct.28|12:16:12 audio/alsa: using device 'default' 2016.Oct.28|12:16:12 [1297] ERROR: TS packet not accepted in Transfer Mode 2016.Oct.28|12:16:13 audio/alsa: start delay 336ms 2016.Oct.28|12:16:13 [1297] [softhddev]Clear: 2016.Oct.28|12:16:13 audio/alsa: using device 'default' 2016.Oct.28|12:16:13 [1297] ERROR: TS packet not accepted in Transfer Mode 2016.Oct.28|12:16:13 audio/alsa: start delay 336ms 2016.Oct.28|12:16:13 [1297] [softhddev]Clear: 2016.Oct.28|12:16:13 audio/alsa: using device 'default' 2016.Oct.28|12:16:13 [1297] ERROR: TS packet not accepted in Transfer Mode 2016.Oct.28|12:16:13 audio/alsa: start delay 336ms 2016.Oct.28|12:16:13 [1297] [softhddev]Clear: 2016.Oct.28|12:16:13 audio/alsa: using device 'default' 2016.Oct.28|12:16:13 [1297] ERROR: TS packet not accepted in Transfer Mode 2016.Oct.28|12:16:13 audio/alsa: start delay 336ms 2016.Oct.28|12:16:13 [1297] [softhddev]Clear:

4 12

[ANNOUNCE] VDR developer version 2.3.4
by Klaus Schmidinger 27 Apr '17

27 Apr '17

VDR developer version 2.3.4 is now available at ftp://ftp.tvdr.de/vdr/Developer/vdr-2.3.4.tar.bz2 A 'diff' against the previous version is available at ftp://ftp.tvdr.de/vdr/Developer/vdr-2.3.3-2.3.4.diff MD5 checksums: 7b1c985d5e7703f7ec46e3818f546702 vdr-2.3.4.tar.bz2 bacbe7b334a4aa0827d95938e3a1ec6d vdr-2.3.3-2.3.4.diff WARNING: ======== This is a *developer* version. Even though *I* use it in my productive environment, I strongly recommend that you only use it under controlled conditions and for testing and debugging. ** IMPORTANT: ** ========== ** ** If you use any of the plugins "ddci2", "satip" or "dvbapi", please make ** sure you get the latest version from their respective repositories! The changes since version 2.3.3: - The functionality of HandleRemoteModifications(), which synchronizes changes to timers between peer VDR machines, has been moved to timers.[ch] and renamed to HandleRemoteTimerModifications(). It now also handles deleting remote timers. - The function cEpgHandlers::BeginSegmentTransfer() is now boolean (thanks to Jörg Wendel). See the description in epg.h for the meaning of the return value. - Changed tEventID back to u_int32_t (suggested by Jörg Wendel). The change to u_int16_t in version 2.3.1 was ill-conceived, because the description of the "event id" in vdr.5 explicitly mentioned this parameter to be 32 bit in size! The members of cEvent have been slightly rearranged to minimize the memory requirements on both 32 and 64 bit systems. - The file 'cam.data' is no longer written if it is read-only. - Detecting whether a particular CAM actually decrypts a given channel is now done separately for each receiver. - The cEvent class now has a new member 'aux', in which external applications can store auxiliary information with an event (thanks to Jörg Wendel). This string has no meaning whatsoever to VDR itself, and it will not be written into the info file of a recording that is made for such an event. - Added some guidelines and recommendations to the 'Logging' section of PLUGINS.html. The most important being: implement a command line option to control the level of logging (in particular allow turning off logging completely!) and never print anything to stdout or stderr (unless one of the listed exceptions applies). - Added a note to the "Pausing live video" section of the MANUAL, stating that the timer for paused live video will always record on the local VDR, even if an "SVDRP default host" has been set for normal timer recordings. - cOsdMenu::Display() now checks whether the OSD size has changed and if so calls SetDisplayMenu(). - The SVDRP commands that deal with recordings (DELR, EDIT, LSTR, MOVR, and PLAY) now use a unique id for each recording, which remains valid as long as this instance of VDR is running. This means that recordings are no longer continuously numbered from 1 to N in LSTR. There may be gaps in the sequence, in case recordings have been deleted, and they are not necessarily listed in numeric order. Thanks to Sergey Chernyavskiy. - Changed 'number' to 'id' in the help texts of SVDRP commands that deal with timers. - Fixed a deadlock in the SVDRP command PLAY in case there is currently a recording being replayed. - Signal strength and quality (CNR) are now determined via DVB API 5 (if available). Fallback is the old DVB API 3 method. - The function cCamSlot::Decrypt() can now also be called with Data == NULL. This is necessary to allow CAMs that copy the incoming data into a separate buffer to return previously received and decrypted TS packets. See ci.h for details. Plugins that implement a derived cCamSlot need to properly handle this case, and plugins that implement a derived cDevice need to call Decrypt() in their GetTSPacket() function even if the incoming buffer is currently empty (see cDvbDevice::GetTSPacket()). - cTSBuffer::Skip() no longer immediately deletes the given number of bytes from the TS buffer, but rather stores the number for later deletion in the next call to Get(). This is necessary because in cDvbDevice::GetTSPacket() tsBuffer->Skip() is called, but the actual TS packet returned (pointed to by Data) may well be (and typically is, unless the CAM copies the data) in the area of the buffer that would be deleted by Skip(). - The new function cDevice::SignalStats() (if implemented by an actual device) returns statistics about the currently received signal. - Updated the Finnish OSD texts (thanks to Rolf Ahrenberg). - Fixed displaying remote timers in the main menu of skin LCARS. - Fixed editing a remote timer immediately after it has been created. - Fixed handling the uncorrected block counter for DVB API 3 devices when calculating signal quality. - The SVDRP command LSTC can now list the channels with channel ids if the option ':ids' is given (suggested by Dietmar Spingler). - If 0 is given as the channel number in the SVDRP command LSTC, the data of the current channel is listed. - Fixed a possible crash when pulling the CAM while decrypting a channel with MTD. Have fun! Klaus

1 0

private cReplayControl::marks
by dev＠cyphermonks.org 22 Apr '17

22 Apr '17

a plugin which wants to act on replaying can get the cControl and access its GetReplayMode() and GetIndex() and the like, but sadly not its marks as they are private. when setting marks when replaying, these seem not to be written until the replaying is ended. so for the plugin there seems to be no way to get the current marks? i guess it would make sense to make the control's marks public or have a public method to get them?

2 1

vdr-convert version 2 released
by Richard F 09 Apr '17

09 Apr '17

I'm pleased to announce that version 2 of vdr-convert has been released over at https://projects.vdr-developer.org/projects/vdr-convert. There are several significant new features: * Option to convert to H265/HEVC via new -v switch, with potential for file size 1/2 of H264, 1/4 of MPEG2 * Multiple format options in single-use/batch modes via -f flag: avi, mkv, mp4, mov, m2ts, ts, aac, m4a and mp3 * A new debug function facilitated testing and the creation of an extensive player/format/stream compatibility matrix at: https://projects.vdr-developer.org/projects/vdr-convert/wiki/Wiki#Compatibi… "/In summary, some players are good for almost all formats, and if you don't need subtitles or automatic aspect ratio switching, most players will play most formats" / * Added support for Fraunhofer AAC codec and libmp3lame codec for mp3 via new -a switch * Added automatic conversion of AC3/DTS streams in VDR1.x recordings (thanks for sample recording contributions from this list) * Added automatic conversion of editing marks to .edl files for Kodi, mplayer in single-use mode * Info, warn and error criticality for different types of problems + optional email at criticality "error" * Conversion runtime + realtime/runtime ratio logged * Wiki extensively updated with new options at https://projects.vdr-developer.org/projects/vdr-convert/wiki +Various other fixes and improvements; todo's cleared Enjoy! Richard

1 0

ISMAR 2017 - Call for workshops
by Myriam Servières 06 Apr '17

06 Apr '17

ISMAR 2017 - CALL FOR WORKSHOPS The ISMAR 2017 organizing committee invites proposals for workshops to be held in the ISMAR 2017 main conference. The workshops will be held on 9th and 13th October 2017, in Nantes, France. The purpose of the workshops is to provide participants with the opportunity to present and discuss research ideas on cutting-edge research topics related to Augmented, Mixed, and Virtual Reality as Science & Technology and Arts, Media, & Humanities. We encourage researchers from different academic communities as well as from industry and public institutions to bring together and to collaborate and discuss with each other about possible future topics and trends. The scope of the proposals should be consistent with the main conference topics. Please visit the conference webpage: http://ismar17.org/ <http://ismar17.org/> Important Dates Workshops Proposal Deadline: April 24th, 2017 Workshops Acceptance Notification: May 2nd, 2017. Deadline Workshops Papers: July 3rd, 2017 Notification Workshops Papers: August 7th, 2017 Workshops Papers Camera Ready Deadline: August 28th, 2017 Workshops Dates: Oct 9th and 13th, 2017. Format ISMAR workshops provide a platform for presentations of novel work, work in progress and position papers. ISMAR workshops may also serve as a platform to actively experience the insights of a variety of pervasive computing topics in seminars. Since seminars aim for a maximum of interactivity, we ask organizers of seminars to focus on proposals of how to involve attendances. This can be for example, by organizing hands-on sessions or pro-contra discussions of reading lists. Workshops may also be organized as a combination of both, resulting in seminars with presentations of novel work, work in progress or position statements. Workshop organizers can choose one out of two options regarding the publication. (1) The workshop's papers will be published in ISMAR 2017 adjunct Proceedings and IEEE Xplore. OR (2) The workshop's papers will not be published but included in the supplemental material folder of the ISMAR 2017 USB memory proceedings. Submission Guidelines for Workshop Proposals Inquiries for workshop submissions can be directed to: wt_chairs(a)ismar17.org <mailto:wt_chairs@ismar17.org> with the subject "ISMAR 2017 workshop proposal" and a PDF document containing: 1. Title of workshop. 2. Preferable date for the workshop: 9/13/no preference. 3. Theme and topics of interest: o Brief description of research issues that the workshop will address. o Reasons why the workshop is of interest to the conference participants. o Reasons why the workshop is timely and relevant for ISMAR 2017. 4. Format of the workshop (including a rudimentary agenda). 5. Interest to get the paper published. 6. Preliminary Call for Papers. 7. Organizers: o Names. o Affiliations. o Research interest. o Short bio. 8. Potential program committee members. 9. Audience: approximate expected number of participants and submissions (range). After sending your proposal to the aforementioned email address, you should receive an acknowledgment of receipt. Workshop proposal will be reviewed by the committee, and notifications of acceptance will be sent out after the review period. Organizers are expected to be proactive in the field where they propose a workshop. Potential workshop organizers should also note that at least one workshop organizer is required to attend those workshops they are organizing. Any change to the workshop organization team must be submitted in writing at least two weeks prior to the workshop paper deadline. No changes to the workshop organization team can be made after this date to ensure that potential participants submitting papers to workshops are aware of the final organization team. Contact ISMAR 2017 Workshop and Tutorial Chairs: wt_chairs(a)ismar17.org <mailto:wt_chairs@ismar17.org> Gerd Bruder, University of Central Florida, USA Myriam Servières, Ecole Centrale de Nantes, France Maki Sugimoto, Keio University, Japan --------- Myriam Servières myriam.servieres(a)ec-nantes.fr <mailto:myriam.servieres@ec-nantes.fr> ISMAR 2017 - Deputy General Chair http://ismar2017.sciencesconf.org <http://ismar2017.sciencesconf.org/>

1 0

ISMAR 2017 - Call for tutorials
by Myriam Servières 06 Apr '17

06 Apr '17

ISMAR 2017 - CALL FOR TUTORIALS The ISMAR 2017 organizing committee invites proposals for tutorials associated with the ISMAR 2017 conference. The tutorials will be held on 9th and 13th October 2017, in Nantes, France. The purpose of the tutorials is to expand the knowledge in the fields of Augmented, Mixed, and Virtual Reality and foster the next generation of researchers, developers, and artists. Important Dates Tutorials Proposal Deadline: April 24th, 2017. Tutorials Acceptance Notification: May 2nd, 2017. Tutorials Dates: Oct 9th and 13th, 2017. Format Experts, pioneers, and experienced developers and artists are needed to propose and present tutorials that may target a specific application area, a specific research area, or a topic of general interest for Augmented, Mixed, and Virtual Reality. Topics can range from introductory for AR/MR/VR novices to highly technical for researchers. Tutorials can be half or full day tutorials, depending on the scope of topics covered and the presenters available. Submission Guidelines To submit a proposal for a tutorial, please send an email to wt_chairs(a)ismar17.org <mailto:wt_chairs@ismar17.org> with the subject "ISMAR 2017 tutorial proposal" and a PDF document containing: Title and topics: Provide a brief summary of the proposed tutorial Preferable date for the tutorial: 9/13/no preference. Motivation: Explain why ISMAR attendees would be interested in attending this tutorial. Explain how an increased knowledge of this subject will advance mixed and augmented reality. Presenters: Provide a really brief bio of the presenters', list of several relevant publications on the proposed topic tutorial, and contact information (e-mail, phone, affiliation) If you have taught this or a similar tutorial before, where and when was it taught. Target Audience: Describe what population this tutorial is targeted towards (e.g., students, industry professionals, everyone). Expected # of attendees. Outline of Tutorial: Include the order of topics and approximate time for each topic. For example: 1. Topic A: 1.5 hours 1.1. Subtopic A1 1.2. ... 2. Topic B: 1.5 hours 2.1. Subtopic B1 ... After sending your proposal to the aforementioned email address, you should receive an acknowledgment of receipt. Tutorial proposal will be reviewed by the committee, and notifications of acceptance will be sent out after the review period. Contact ISMAR 2017 Workshop and Tutorial Chairs: wt_chairs(a)ismar17.org <mailto:wt_chairs@ismar17.org> Gerd Bruder, University of Central Florida, USA Myriam Servières, Ecole Centrale de Nantes, France Maki Sugimoto, Keio University, Japan --------- Myriam Servières myriam.servieres(a)ec-nantes.fr <mailto:myriam.servieres@ec-nantes.fr> ISMAR 2017 - Deputy General Chair http://ismar2017.sciencesconf.org <http://ismar2017.sciencesconf.org/>

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

vdr April 2017