DVR+ Lister for Channel Master DVR+ - Page 15 - AVS Forum | Home Theater Discussions And Reviews
View Poll Results: Do you move DVR+ recordings to a computer (multiple choices allowed)
Yes, Windows 37 49.33%
Yes, Linux 9 12.00%
Yes, Mac 4 5.33%
Yes, Other OS 1 1.33%
No 28 37.33%
Multiple Choice Poll. Voters: 75. You may not vote on this poll

Forum Jump: 
 77Likes
Reply
 
Thread Tools
post #421 of 440 Old 06-19-2017, 09:21 AM - Thread Starter
AVS Forum Special Member
 
pachinko's Avatar
 
Join Date: Jan 2014
Posts: 1,274
Mentioned: 46 Post(s)
Tagged: 0 Thread(s)
Quoted: 834 Post(s)
Liked: 440
Quote:
Originally Posted by kaye View Post
If the software works, I'll post the csv files so you can look at them.
Your C++ programs seem to work just fine. I downloaded and installed codeblocks-16.01mingw-setup.exe from Code::Blocks downloads page (it's freeware), compiled and ran both of your C++ programs, piping their output to csv files, and imported the csv's into Excel where they looked good to me. But yeah, post what you get and any insights you may have.

For those interested, Code::Blocks includes an IDE (although I did not use it), and supports C, C++ and Fortran. If installed in the default location, the g++.exe compiler will be found in "C:\Program Files (x86)\CodeBlocks\MinGW\bin\"
pachinko is online now  
Sponsored Links
Advertisement
 
post #422 of 440 Old 06-20-2017, 07:34 AM
Member
 
Join Date: Feb 2017
Posts: 16
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 15 Post(s)
Liked: 11
Update on Spanish files

Thank you for the Spanish channel data.

Attached is a zip file of the csv (comma separated variable) of the rei and streaminfo files. It was prepared using the previously posted code. The csv should be able to be directly opened in any spreadsheet program. If formatting information is needed for the spreadsheet program, then the file has variables separated by commas and text enclosed in double quotation marks. Also, there is a text file of the information generated by MediaInfo on the Strm0004.ts file. It will have Linux line feeds, so you will need to use Wordpad or similar more advanced text viewer if it appears to be a jumble of one continuous line.

I see that you did download a C++ compiler and had success with installing it and running my code. Looks like CodeBlocks is a GUI front end for compilers, but you also picked up the MingW C++ compiler which is the Windows version of the GNU C++ compiler that I am using. If you are interested in the internals of the *.ts files, the MediaInfo program that I am using is available in a Windows version as well.

I was able to view the Strm0004.ts file and have Spanish only audio. I have not been able to directly view the closed caption, I assume from your post it is in Spanish. I was able to convert the file and see about 1 second of what appears to be a Spanish phrase at the very end of the recording. I will have to wait to see the captions when I reformat my flash drive and can load your recordings on it so I can view it on the DVR+.

The streaminfo file gives the (first) audio channel as und - undetermined. It should be spa - Spanish. The und matches what the DVR+ menu is giving. There are two possible causes of this:
* First, the television station itself may be embedding incorrect data into the program.
* Second, there may be a bug in the Channel Master software. If there is a bug, then it appears that the DVR+ is programmed to expect the first language to be English and the second Spanish (see previous post). If anything is different for the first language then it tags it as "und" and exits the streaminfo storage routine. It appears to then not make any notation on closed captioning in the streaminfo file.

The closed caption area of the streaminfo file is blank. It does not list any closed caption service. The DVR+ menu appears to be coded to display 4 cc services, and call each one as requested. It displays nothing if the service is not embedded in the sub-channel stream when you select it. Without the data in the streaminfo file, it will be interesting to see if any closed captioning is displayed by the DVR+ on the Strm004.ts file. If it is, then the DVR+ is picking up its cc information in at least one more place.

As an aside, you can see the audio channel is listed as 2 channels in the MediaInfo data. The streaminfo file shows that Strm0004.ts has 2 channels (stereo). The very first record in the streaminfo file is showing 5.1, demonstrating what I have seen before - that the audio channel information is dependent upon prior history until it "locks on" to the audio channel data.

Longer term it would be up to Channel Master to view several Spanish stations to see if their code has problems or if it was a problem due to errors on the single station you recorded. I would bet it is a Channel Master issue. An easy confirmation is if your television receiver has the capability of displaying language information, without going through the Channel Master unit. Of course it probably does the same as mine, simply giving it as audio1, audio2, etc. and not worrying about the language being broadcast.

In the short term it may not have a great effect, since the key data piece that there is only one audio channel and the channel ID is 52 is intact in the streaminfo file. Any coding using the streaminfo data would be correct, since und is a viable language code, just not as correct as it should be.

I will continue to look at the rei and streaminfo data as time permits. I am considering how to use bit editing to affect the streaminfo file and see what happens when I work with the variables. I found out a lot when I did this with the rei file data. The Spanish recording will be invaluable at that time. Thank you again.
Attached Files
File Type: zip spanish.zip (14.2 KB, 2 views)
pachinko likes this.
kaye is offline  
post #423 of 440 Old 06-20-2017, 08:08 AM
AVS Forum Special Member
 
P Smith's Avatar
 
Join Date: Apr 2003
Location: Mediterranean Sea
Posts: 3,039
Mentioned: 16 Post(s)
Tagged: 0 Thread(s)
Quoted: 625 Post(s)
Liked: 325
Quote:
Originally Posted by kaye View Post
...
The closed caption area of the streaminfo file is blank. It does not list any closed caption service. ...
I would suggest to research the TS file, pretty sure CC metadata is there; my favorite analyzer/player is VLC - it will show all services, if PAT/PMT would be rebuild from SI and added to the TS file.
P Smith is offline  
 
post #424 of 440 Old 06-20-2017, 02:39 PM - Thread Starter
AVS Forum Special Member
 
pachinko's Avatar
 
Join Date: Jan 2014
Posts: 1,274
Mentioned: 46 Post(s)
Tagged: 0 Thread(s)
Quoted: 834 Post(s)
Liked: 440
Quote:
Originally Posted by kaye View Post
...
...
I was able to view the Strm0004.ts file and have Spanish only audio. I have not been able to directly view the closed caption, I assume from your post it is in Spanish. I was able to convert the file and see about 1 second of what appears to be a Spanish phrase at the very end of the recording. I will have to wait to see the captions when I reformat my flash drive and can load your recordings on it so I can view it on the DVR+.
...
The closed caption area of the streaminfo file is blank. It does not list any closed caption service. The DVR+ menu appears to be coded to display 4 cc services, and call each one as requested. It displays nothing if the service is not embedded in the sub-channel stream when you select it. Without the data in the streaminfo file, it will be interesting to see if any closed captioning is displayed by the DVR+ on the Strm004.ts file. If it is, then the DVR+ is picking up its cc information in at least one more place.

As an aside, you can see the audio channel is listed as 2 channels in the MediaInfo data. The streaminfo file shows that Strm0004.ts has 2 channels (stereo). The very first record in the streaminfo file is showing 5.1, demonstrating what I have seen before - that the audio channel information is dependent upon prior history until it "locks on" to the audio channel data.

Longer term it would be up to Channel Master to view several Spanish stations to see if their code has problems or if it was a problem due to errors on the single station you recorded. I would bet it is a Channel Master issue. An easy confirmation is if your television receiver has the capability of displaying language information, without going through the Channel Master unit. Of course it probably does the same as mine, simply giving it as audio1, audio2, etc. and not worrying about the language being broadcast.
...
I'm not seeing any CCs either in any of my Windows video players, nor does CCExtractor find any, but they definitely appeared on the DVR+ (you'll see them when you use your flash drive).

Today I made a 29 second (35.8MB) recording on the same Telemundo channel (click HERE to download), clearly showing subtitles, and again no subtitles show on the PC even though there is a lot of conversation. None of the data are from the data I uploaded yesterday (I deleted everything and started anew), so don't mix them. I couldn't get the zip to upload to tinyupload, so had to upload to DropBox, and I hope the download works for you if you want it. If DropBox tries to force you to sign up, you do not, just click the "No Thanks..." hyperlink.

I do have MediaInfo v0.7.96 for Windows, and is reveals 2 text streans EIA-608 and EIA-708 on the new Strm0008 recording, as well as on Strm0004 from yesterday as you already know.

Unfortunately, my TV only shows CC (Service 1), with no hint of the language. There's another Spanish channel in my area (V-me), but it only broadcasts its Call Sign and music, so likely of no value unless you'd like to have a sample for who knows what.

For those interested, the following command line is what I use in order to get VLC to play the DVR+ produced (videos which are missing the PAT/PMT data).

"C:\Program Files (x86)\VideoLAN\VLC\vlc.exe" --demux ffmpeg
pachinko is online now  
post #425 of 440 Old 06-20-2017, 05:50 PM - Thread Starter
AVS Forum Special Member
 
pachinko's Avatar
 
Join Date: Jan 2014
Posts: 1,274
Mentioned: 46 Post(s)
Tagged: 0 Thread(s)
Quoted: 834 Post(s)
Liked: 440
Quote:
Originally Posted by kaye View Post
...I was able to convert the file and see about 1 second of what appears to be a Spanish phrase at the very end of the recording. ...
Based upon this, I remuxed yesterdays Strm0004.ts and todays Strm0008.ts using VideoRedo, then used CCExtractor to create an SRT file for each. I've attached a small ZIP file containing both SRT files. But without the SRT files, the remuxed copies still do not show subtitles when played on the PC.
Attached Files
File Type: zip SRT for Strm0004 and Strm0008.zip (869 Bytes, 2 views)

Last edited by pachinko; 06-20-2017 at 05:53 PM.
pachinko is online now  
post #426 of 440 Old 06-21-2017, 08:00 AM
Member
 
Join Date: Feb 2017
Posts: 16
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 15 Post(s)
Liked: 11
P Smith breakout of Streaminfo

Quote:
Originally Posted by P Smith View Post
Do you have any comments to posts 316 and 341 ?
Your request was for a comparison of the streaminfo data record structures. This is what I perceive in combining the two interpretations.

typedef struct _K77_STREAMINFO_ENTRY
BYTE bVideoPIDs; // count
BYTE bAudioPIDs; // count
WORD unk_02;
WORD wPCR; // PCR usually same as VPID1
WORD unk_06;

// video info by count = bVideoPIDs; should be max 2
WORD wVPID1;
WORD wVPID1type; // = 0105 / 0002

WORD wVPID2;
WORD wVPID2type;

// video langs part
BYTE wnVLangs; // number langs =1/2/3
BYTE wnVLangs_rsv[3]; // =0
// first VLang item
char cVLang[4];
BYTE bVLangId; // = 05
BYTE bVLang_19; // = 00
BYTE wVLang_rsv[2];
// next VLang item
BYTE b_1c[0x84]; //

>The first byte in this structure is bVideoPIDs which corresponds to my byte 1 for number of video streams.
>The second byte in this structure is bAudioPIDs which corresponds to my byte 2 for number of audio streams.
>Next a word unk_02 corresponds to my bytes 3-4 with unknown purpose.
>Next a word wPCR which roughly corresponds to a combination of my byte 5 which is video stream id number and byte 6 which is unknown and appears not to be used.
>Next a word unk_06 corresponds to my byte 7-8 which is unknown and appears not to be used.
>Next a word wVPID1 which duplicates wPCR and corresponds to a combination of my byte 9 which is video stream id number and byte 10 which is unknown and appears not to be used-also duplicating bytes 5-6.
>Next a word wVPID1type (values 0105 or 0002). This differs to my interpretation of bytes 11-12 as the audio channel type where 2 is stereo and 5.1 is surround sound. There is a correspondence with audio channel during recording, but it is not perfect and appears to be dependent upon multiple extraneous factors.
>Next is a pair of words wVPID2 and wVPID2type. This differs to my interpretation of bytes 13-16 as unknown. Present TV broadcasts are allowed only one video stream per sub-channel so I am not convinced it is a second video stream information area. Of course it could be a place holder for such information in the future,

>Your next section is video languages which corresponds to the closed caption fields. They are a repeating section. You appear to allow for 3 repeats, I am assuming 4 repeats due to the DVR+ having 4 closed caption options.
>First is byte wnVLangs which corresponds to my byte 17 number of closed caption streams used.
>Second is three bytes wnVLangs_rsv which corresponds to my 3 byte unknown.
>Third is a 4 byte character array cVLang which corresponds to my 3 byte closed caption language code plus an additional byte which is always 0. Indeed, these language codes may be null terminated strings.
>Fourth is byte bVLangId which corresponds to my byte 25 unknown item. If you have an idea as to the byte's purpose please let me know. I have seen values of 4, 5 and 9 but predominately 5.
>Fifth is byte bVLang_19 which corresponds to my byte 26 unknown but value 0. Do you have a function in mind for this byte since it is named, or is it a placeholder to get to a word boundary?
>Sixth is a 2 byte array wVLang_rsv which corresponds to my bytes 27-28 unknown but values of 0.
>At this time you skip down to the audio section of the record with a notation of next video language, whereas I repeat the closed caption service section a total of 4 times.


typedef struct _K77_STREAMINFO_APID_ENTRY
WORD wAPID;
WORD wAPIDtype; // = 010e
DWORD rsv;
char cALang[4]; // "und"/"eng"/"esl"/"spa"/"fre"/"chi"...
BYTE bLangId; // = 04
BYTE bALang_rsv[3];

This is your audio information record entry creating an array of 18 elements. I have a similar entry but have only 2 repeats, not yet finding a third + audio source to check how many audio elements the DVR+ will respond to. This is an area where I may try some bit manipulation of the streaminfo file to see what happens.
>First word in this structure is wAPID which corresponds to a combination of my byte 161 audio 1 stream ID number and byte 162 which is unknown and appears not to be used.
>Second word is wAPIDtype which corresponds to my bytes 163-164 of an unknown item.
>Third is double word rsv which corresponds to my bytes 165-168 of an unknown item but values of 0.
>Fourth is 4 byte character array cALangID which corresponds to my 3 byte audio 1 language code plus an additional byte which is always 0. Once again, these language codes may be null terminated strings.
>Fifth is a byte bLangID which corresponds to my byte 173 unknown item but value of 4.
>Sixth is a 3 element byte array bALang_rsv which corresponds to bytes 174-176 of an unknown item but values of 0.
>At this point you continue to repeat the array, whereas I give a second audio entry only and leave the rest empty.


Overall, the records are very similar except for the number of repeats of the video, closed caption and audio entry structures. I am trying to leave mine with the minimum number of repeats as experienced from the DVR+.

One real difference is in the utilization of wVPID1type within the video entry. In the second referenced post you stated the example of a streaminfo file with elements 2 and 7 having values of 51 instead of the usual 2, and suggested unsuccessfully that they could be codes for 720p or 1080i etc. My interpretation would be the audio channel being stereo vs surround sound. Once again this value is not dependable, with history, menu settings and the DVR+ live record and a "feature" of at times grabbing the live record and adding it to the recording all playing a part. My interpretation would not provide a clean sectioning of the streaminfo file. However I am leaving the next bytes as open where you are repeating a second video information area. I believe that FCC/television rules stipulate only one video stream per the sub-channel so leaving the area open allows for other uses of the space. While there is a correlation for the audio channel to this entry, I am not confident that my interpretation is correct. I have never seen a value of 5.1 for any sub-channel that broadcasts only in stereo (oldies stations) but a jumble of 5.1 and 2 for multi audio stream setups. Right now I can find no utilization for this data anyway.

One area that we do not have a handle on is data streams are allowed to be muxed into channels. I do not know of any being performed in actual practice, but some of the record area could be reserved for this.

One area needing attention is the audio stream area, where there are multiple values being stored to unknown purpose. I think one of these may be a code for AC3 style audio, since I believe differing audio types are allowed by the FCC to be broadcast. I am still looking for a good reference to what the codes for these audio types would be to see if any match.

The video language/closed capture area is also needing some attention. However, when looking at my information I think there may be a number of bugs in the DVR+ software in this area. The one thing that might help is a one minute recording of CW Supergirl which showed two records in a previous post. My attempts have been thwarted at duplicating this due to the local station usurping the feeds in an emergency and a second attempt where no closed caption information was recorded in the streaminfo file. My older version of the DVR+ software may have a bug that failed when two services were available and the newer version that made this record may have been fixed. I am just afraid to update since my system is working and I have read posts where the updates introduced new issues that I would like to avoid. It also appears that the DVR+ may be using a second source for this information, with closed captions being displayed without a record. I need to look at this further. It is also possible that the DVR+ is merely recording the cc information as a log, and actually blindly requesting the captioning from the video stream using a universally defined stream code.

I am going to see if I can perform some bit manipulations to stress test the streaminfo file to gather more information. But this may take a while due to time constraints.
kaye is offline  
post #427 of 440 Old 06-21-2017, 08:40 AM
Member
 
Join Date: Feb 2017
Posts: 16
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 15 Post(s)
Liked: 11
Quote:
Originally Posted by P Smith View Post
I would suggest to research the TS file, pretty sure CC metadata is there; my favorite analyzer/player is VLC - it will show all services, if PAT/PMT would be rebuild from SI and added to the TS file.
Quote:
Originally Posted by pachinko View Post
I'm not seeing any CCs either in any of my Windows video players, nor does CCExtractor find any, but they definitely appeared on the DVR+ (you'll see them when you use your flash drive).

Today I made a 29 second (35.8MB) recording on the same Telemundo channel, clearly showing subtitles, and again no subtitles show on the PC even though there is a lot of conversation.

I do have MediaInfo v0.7.96 for Windows, and is reveals 2 text streans EIA-608 and EIA-708 on the new Strm0008 recording, as well as on Strm0004 from yesterday as you already know.
Thank you for the additional recording. I do not think that additional recordings of a channel of only audio will help in the closed capture area.

I am 99% certain the streams are still in the *.ts file. My looking at it after converting the small one appears to confirm this. When I do the larger one I should have enough time to see the captions.

I can see the captions on the PC using VideoLAN and a converted file that holds a PAT/PMT. My technique for doing the conversion is very simple. I am using the program AVIDEMUX (Windows version available). Using copy mode for both the audio and video channels and saving as a mpeg TS file type. This will then play directly. One problem is my version of avidemux allows only one audio stream to be copied from the original file, though you can add a second stream from an external file.

I am slowly becoming convinced that the DVR+ is blindly requesting the CC via a universal metadata code. At times the streaminfo file has no cc data, yet the DVR+ is displaying CC1. I have access to some very complex video editing software in the Adobe Cloud, but it is so complex it is going to be difficult to use. But I may be able to affect the metadata for all the streams and see what happens when it is loaded into the DVR+. There is also editing the streaminfo file for affects.

What may be interesting is whether the addition of the PAT/PMT is actually adding data on the CC streams, or it is merely necessary to be present for programs such as VideoLAN to do a blind request for CC output. I do know that using the ffmpeg demux in VideoLAN and playing an original *.ts file will not show CC. Using the conversion and standard demux VideoLAN will show CC.

I need to cross reference the PMT data structure and what is found in the streaminfo file.
kaye is offline  
post #428 of 440 Old 06-21-2017, 09:49 AM
AVS Forum Special Member
 
P Smith's Avatar
 
Join Date: Apr 2003
Location: Mediterranean Sea
Posts: 3,039
Mentioned: 16 Post(s)
Tagged: 0 Thread(s)
Quoted: 625 Post(s)
Liked: 325
Thanks you kaye for your analysis; for forgiveness of my errors/omissions/suggestions, I can say the structures has been derived from TR-50 structures and little bit verified by files from K77 more then 3 years ago. Since that time I lost ability to work with DVR+ and switched to its predecessor, original UK version HDR-610R. But that model has different source of data [based on DVB-T/T2]. I did check many times for TR-50, my generated PAT/PMT by SI file info perfectly works for all all A/V PIDs. While I never check CC metadata, actually found it works regardless what I missed from SI file when rebuilt PAT/PMT. Also I found no use or what that unknown "type" of sub-streams V or A in SI file means. Perhaps it's just e* internal indexes for FW use only. All necessary DVB types I did extract from analyzing A/V metadata of first chunk of TS [TSP] files, 1 or 2 MB.
P Smith is offline  
post #429 of 440 Old 06-21-2017, 12:39 PM - Thread Starter
AVS Forum Special Member
 
pachinko's Avatar
 
Join Date: Jan 2014
Posts: 1,274
Mentioned: 46 Post(s)
Tagged: 0 Thread(s)
Quoted: 834 Post(s)
Liked: 440
Quote:
Originally Posted by kaye View Post
...
My older version of the DVR+ software may have a bug that failed when two services were available and the newer version that made this record may have been fixed. I am just afraid to update since my system is working and I have read posts where the updates introduced new issues that I would like to avoid. ...
I certainly understand your reluctance to install another DVR+ version, but unless you are running a version that was not made available for download (such as 115R), you can install any available version, and later return to your favorite version. It's a fairly simple "Maintenance Reset" process, and I have done it many times, including recently reverting from 134R to 132R. No settings or recordings are lost, although sometimes the WiFi password may be required if the dongle was unplugged and not reconnected before the DVR+ boots.

Click HERE to go to wiscojim's post where a link to a DropBox account containing all 10 available DVR+ updates can be downloaded, including 114R. I suggest that you download all of them for safe keeping!

Here's my post on installing updates using the Maintenance Reset procedure.

Below is a YouTube video by Channel Master on installing updates using the Maintenance Reset method. It is somewhat outdated (for example, the Channel Master web pages have changed, the download is not hosted by Dropbox, etc.), it overlooks a couple of things (like formatting the Flash Drive to FAT32), the camera angle doesn't allow seeing the LED color changes (Mike has his hand in the way), and of course CM only posts the latest version, but in general it will give you an idea of the process. Mike also unplugs the USB EHD without using the menu system to properly disconnect it, which is not the best idea.

Quote:
Originally Posted by kaye View Post
...
I am 99% certain the streams are still in the *.ts file. ...
I am 100% certain that the CC data are in the TS file, because when I remuxed the TS files, with VideoReDo, I did so with the TS files being the only files in the folder, so VideoReDo could not possibly acquire those data from anywhere else, and CCExtractor easily created SRT files from the remuxed TS files, while it finds no subtitles in the original TS files.
pachinko is online now  
post #430 of 440 Old 06-24-2017, 08:35 AM
Member
 
Join Date: Feb 2017
Posts: 16
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 15 Post(s)
Liked: 11
Languages

The attached report concerns the utilization of language codes in the television broadcast industry.

Short summary: Many receivers do not accurately utilize the language codes in menus and language selection. To compensate for this, some broadcasters are sending out "incorrect" codes to make their signal compatible with the populace, not the standard.

So there is no way to see if the DVR+ is correctly responding to input information or whether the broadcasters are sending bad data - especially since the DVR+ appears to be stripping the PAT/PMT data from the recording.

I may continue to look at a couple of tests of the language codes and DVR+, but it appears to be a moot point. Other sections of the streaminfo file potentially need to be addressed. However, key elements of the streaminfo file on stream identification are still correct and usable if someone generates a PAT/PMT routine. P. Smith appears to have demonstrated this in a DVB setting. It just will not have all the information that it potentially can have.

The original ASTC specification required the language codes be in the PMT and none in the AC3 file. They then changed their minds and made the PMT optional and the AC3 file mandatory.

MediaInfo does give language codes for several file types, just not AC3 - so there is no way to track what is actually present. I looked at the AC3 code section of the MediaInfo library and it is too complex for a quick patch without knowing a great deal more about the program structures and techniques.

As to the audio type information, it may be some of the unknown variables in the streaminfo file. While AC3 is the audio type, the standard allows for normal AC3 and an extended/enhanced E-AC3 audio type. They have different code numbers in the specification. I don't know if this would affect the PMT.
Attached Files
File Type: pdf TG1-1013r1-Technology-Group-Report-on-ATSC-Audio-Language-Signaling.pdf (88.5 KB, 3 views)
pachinko likes this.
kaye is offline  
post #431 of 440 Old 06-28-2017, 07:33 AM
Member
 
Join Date: Feb 2017
Posts: 16
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 15 Post(s)
Liked: 11
Update Program Streaminfo

I have attached an updated file that I am using to break down and view the streaminfo file. It is written in c++ and is readily modifiable if anyone is interested in viewing data contained in that file.

The original file assumed the video and audio ids were normal bytes. In reviewing some data from Pachinko I found one instance of these ids being greater than 128. These were being displayed as negative numbers. Therefore the ids are stored as unsigned bytes. This updated file corrects that assumption.

Please replace the original file with this updated version. Sorry for the confusion.
Attached Files
File Type: zip stream2.zip (3.7 KB, 4 views)
pachinko likes this.
kaye is offline  
post #432 of 440 Old 08-06-2017, 05:20 PM
Newbie
 
Join Date: Jan 2015
Posts: 2
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 1 Post(s)
Liked: 1
I'm getting an array overflow error when I attempt to load my REI file. Any suggestions?
Attached Thumbnails
Click image for larger version

Name:	Screenshot (2).png
Views:	7
Size:	91.4 KB
ID:	2263988  
Attached Files
File Type: zip record_event_index.zip (27.3 KB, 4 views)
littlebrownjug is offline  
post #433 of 440 Old 08-06-2017, 07:08 PM
AVS Forum Special Member
 
JHBrandt's Avatar
 
Join Date: Apr 2008
Location: S. Garland, TX
Posts: 4,813
Mentioned: 25 Post(s)
Tagged: 0 Thread(s)
Quoted: 1719 Post(s)
Liked: 847
I looked at your REI file and couldn't see any obvious problem; but the good news is Pachinko's "Beta 4" version parses your file fine, so I'm sure he can fix the production version. Beta 4 doesn't even report an error on entry 339, let alone blow up!

BTW, entry 339, which DVR+ Lister is blowing up on, is the very last nonblank entry in your REI file. Guess that's just the luck of the draw.
JHBrandt is offline  
post #434 of 440 Old 08-06-2017, 07:23 PM - Thread Starter
AVS Forum Special Member
 
pachinko's Avatar
 
Join Date: Jan 2014
Posts: 1,274
Mentioned: 46 Post(s)
Tagged: 0 Thread(s)
Quoted: 834 Post(s)
Liked: 440
Quote:
Originally Posted by littlebrownjug View Post
I'm getting an array overflow error when I attempt to load my REI file. Any suggestions?
Welcome to the AVS Forum, and to DVR+ Lister!

Because you attached your REI file, I am able to know precisely what's wrong. The problem is that the show description for strm00DA (This Old House) contains a vertical bar, and the REI parser uses that character for a delimiter when it splits data into an array (the error you get). This one can be blamed on the programmer, me!

But you don't care about that, you just want DVR+ Lister to work! Right? The fastest way to get you going is to provide you with an edited REI file that replaces that one vertical bar, and the space before and after it, with three hyphens. You will see those three hyphens in the description for show strm00DA when the data loads into DVR+ Lister. The edited REI file is attached, and to keep from writing over you original file, I altered the file name. Do NOT copy that file to the USB disk, but put it in a folder on your computer's hard disk, then rename it to "record_event_index" or DVR+ Lister will not accept it. Then, instead of pointing DVR+ Lister to the REI file on the USB disk, direct it to the edited REI file. For the TS recording path, use the USB disk.

I'll update DVR+ Lister to avoid this issue, and post the update in the near future, but I'm wrestling with what version number to give it so that it's not a later version number that the Beta 16.9.1 release.

FYI, the released Beta 16.9.1 has the same problem.
Attached Files
File Type: zip record_event_index(edited by pachinko - 2017-08-06).zip (28.1 KB, 2 views)
pachinko is online now  
post #435 of 440 Old 08-06-2017, 07:38 PM
AVS Forum Special Member
 
JHBrandt's Avatar
 
Join Date: Apr 2008
Location: S. Garland, TX
Posts: 4,813
Mentioned: 25 Post(s)
Tagged: 0 Thread(s)
Quoted: 1719 Post(s)
Liked: 847
I seem to remember the vertical bar issue being one of the many problems my corrupted REI file caused in the Beta 1 version.

As for a version number for the fix, it sounds like you need a suffix. Something like Version 15.7.3A.
JHBrandt is offline  
post #436 of 440 Old 08-06-2017, 07:41 PM - Thread Starter
AVS Forum Special Member
 
pachinko's Avatar
 
Join Date: Jan 2014
Posts: 1,274
Mentioned: 46 Post(s)
Tagged: 0 Thread(s)
Quoted: 834 Post(s)
Liked: 440
Quote:
Originally Posted by JHBrandt View Post
I looked at your REI file and couldn't see any obvious problem; but the good news is Pachinko's "Beta 4" version parses your file fine, so I'm sure he can fix the production version. Beta 4 doesn't even report an error on entry 339, let alone blow up!

BTW, entry 339, which DVR+ Lister is blowing up on, is the very last nonblank entry in your REI file. Guess that's just the luck of the draw.
Actually, recording 339 is not the cause (it's recording 218, strm00DA), but as you've noticed 330 is the last recording in the REI file. The error occurs just after reading all recording data from the REI when an array is built, and the message window the DVR+ Lister displays showing the 339 count just happens to be still open, because the dumb programmer didn't think a crash would occur there!!!

For those interested, the error window that AutoIt, displays for complied programs, is nearly useless. The reason that I can find precisely where the error occurs is because I run the program in the SciTE4AutoIt3 editor, and that traps the line in the source code files where the error occurs. But, you'll need both AutoIt and SciTE4AutoIt3 installed (they're both free programs with no restrictions), and know a little bit about programming in AutoIt.
pachinko is online now  
post #437 of 440 Old 08-06-2017, 07:47 PM - Thread Starter
AVS Forum Special Member
 
pachinko's Avatar
 
Join Date: Jan 2014
Posts: 1,274
Mentioned: 46 Post(s)
Tagged: 0 Thread(s)
Quoted: 834 Post(s)
Liked: 440
Quote:
Originally Posted by JHBrandt View Post
I seem to remember the vertical bar issue being one of the many problems my corrupted REI file caused in the Beta 1 version.

As for a version number for the fix, it sounds like you need a suffix. Something like Version 15.7.3A.
Yep, that vertical bar was one of the issues, and it's fixed in the 19.9.1 beta 4 version that only you and I have, and in the unreleased DVR+Explorer that I really need to complete one day!

Thanks for the suggestion on the version number. I was thinking the same thing for the version number!

FYI, you still have the record for the worse messed up REI file!
pachinko is online now  
post #438 of 440 Old 08-06-2017, 08:55 PM - Thread Starter
AVS Forum Special Member
 
pachinko's Avatar
 
Join Date: Jan 2014
Posts: 1,274
Mentioned: 46 Post(s)
Tagged: 0 Thread(s)
Quoted: 834 Post(s)
Liked: 440
DVR+ Lister v15.7.3.1 (August 6, 2017)
(sorry, this time the version number does not indicate the release date)


Go to the bottom of this post for v15.7.3.1 Download links

For the latest version, and other information about this program, always check the first post in this thread.

Check top of post 1 for a poll.





What’s New or Changed:

1. Same as version 15.7.3, but with one bug fix (see below)



Bug Fixes:

1. Fixed bug that caused the program to crash with an array error when the Show Title or the Show Description contained a vertical bar character. The fix replaces the vertical bar with a hyphen (it does NOT alter data on the USB disk).




Installation:

1. If you intend to install over an older version, do the following:
.
a. Safeguard the file DVR+ Lister.ini, so that all previous settings and filters are retained.

b. Safeguard the file LastSessionData.txt, if the data from the last session is important to you.

c. Delete all other files (not folders), other than any you may have added.

d. Delete the Source and Help Source folders if they exist, unless of course you've edited any of those files, in which case rename those folders and retain for your use.
2. Download, and extract into a folder of your choice. That folder must allow write access to it by this program. Two sub-folders are created (Source and Help Source). Those folders contain the Source Files should you want to modify the program. They are NOT required to run the program and can be deleted if not desired.


3. If installed into a new folder, and you have an older version installed, copy the following files from the old version:
.
a. DVR+ Lister.ini (all previous settings and filters).

b. LastSessionData.txt (the data from the last session, if that's important to you).

.
Running the Program:

Run the program directly by double-clicking 'DVR+ Lister.exe', or make a shortcut for it and put it on the Taskbar, the Desktop, or in the Programs menu (or wherever desired), and use the shortcut to run the program. There are 2 EXE files, but only 'DVR+ Lister.exe' should be executed. It runs the second EXE automatically (only when recordings are being copied).

Note: In order for Windows computers to recognize and assign drive letters to the DVR+ USB HDD (a Linux format), the program Ext2Fsd, or similar, must be installed in Windows.



Uninstalling:

1. Delete the directory containing all of the DVR+ Lister files, provided that's all it contains.
2. Delete all Shortcuts, wherever they were placed.
3. There are no entries in the Windows Registry, so nothing to do in it!



Programming Language:

DVR Lister 15.7.3.1 is written and compiled in AutoIt version 3.3.15.0 (beta). AutoIt version 3.3.14.2 (the current version) was also tested. Either version can be used to recompile the program.



Sample Logs and TS files (a 15MB download):

If you would like to try DVR+ Lister without having to attach the USB HDD, from the DVR+, to a Windows computer, you can download some sample files and put them on your computer. Then point DVR+ Lister to the folders where you put the samples. See post 1 for the download link.



Download Options:


Download from the attachments to this post (see below - all 5 required). A single zip file containing all files is not provided for this release.

Note about attachments:
In order to attach DVR+ Lister, and adhere to the forum limitation of 977KB per attachment, the program had to be compressed into a series of spanning ZIP files, and their file type renamed to .ZIP so that they could be attached. They are the 5 attachments. You’ll need all 5 in order to unZIP. They contain ALL of the DVR+ Lister files (the Executables, the CHM help file, and all Source Files). After downloading, remove the .ZIP extension from z01, z02. z03,and z04 (leave the "z" number), then unZIP (assuming your extractor supports spanned ZIP files).
Attached Files
File Type: zip DVR+ Lister (v15.7.3.1).zip (813.0 KB, 18 views)
File Type: zip DVR+ Lister (v15.7.3.1).z01.zip (900.0 KB, 16 views)
File Type: zip DVR+ Lister (v15.7.3.1).z02.zip (900.0 KB, 17 views)
File Type: zip DVR+ Lister (v15.7.3.1).z03.zip (900.0 KB, 17 views)
File Type: zip DVR+ Lister (v15.7.3.1).z04.zip (900.0 KB, 18 views)

Last edited by pachinko; 08-07-2017 at 09:19 AM.
pachinko is online now  
post #439 of 440 Old 08-07-2017, 10:56 AM
AVS Forum Special Member
 
JHBrandt's Avatar
 
Join Date: Apr 2008
Location: S. Garland, TX
Posts: 4,813
Mentioned: 25 Post(s)
Tagged: 0 Thread(s)
Quoted: 1719 Post(s)
Liked: 847
Quote:
Originally Posted by pachinko View Post
Actually, recording 339 is not the cause (it's recording 218, strm00DA), but as you've noticed 330 is the last recording in the REI file. The error occurs just after reading all recording data from the REI when an array is built, and the message window the DVR+ Lister displays showing the 339 count just happens to be still open, because the dumb programmer didn't think a crash would occur there!!!
Funny thing is, I actually scanned through all the show titles & descriptions visually, looking for an odd character (like the vertical bar), but I totally missed it. It's hard to see a needle like that buried in a haystack of text! You really need the debugger to find problems like this.
pachinko likes this.
JHBrandt is offline  
post #440 of 440 Old 08-07-2017, 07:49 PM
Newbie
 
Join Date: Jan 2015
Posts: 2
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 1 Post(s)
Liked: 1
Quote:
Originally Posted by pachinko View Post
Welcome to the AVS Forum, and to DVR+ Lister!

Because you attached your REI file, I am able to know precisely what's wrong. The problem is that the show description for strm00DA (This Old House) contains a vertical bar, and the REI parser uses that character for a delimiter when it splits data into an array (the error you get). This one can be blamed on the programmer, me!

But you don't care about that, you just want DVR+ Lister to work! Right? The fastest way to get you going is to provide you with an edited REI file that replaces that one vertical bar, and the space before and after it, with three hyphens. You will see those three hyphens in the description for show strm00DA when the data loads into DVR+ Lister. The edited REI file is attached, and to keep from writing over you original file, I altered the file name. Do NOT copy that file to the USB disk, but put it in a folder on your computer's hard disk, then rename it to "record_event_index" or DVR+ Lister will not accept it. Then, instead of pointing DVR+ Lister to the REI file on the USB disk, direct it to the edited REI file. For the TS recording path, use the USB disk.

I'll update DVR+ Lister to avoid this issue, and post the update in the near future, but I'm wrestling with what version number to give it so that it's not a later version number that the Beta 16.9.1 release.

FYI, the released Beta 16.9.1 has the same problem.
Gosh guys!! You're terrific! Not only a workaround but a permanent fix as well. Used patched REI to do all my transfers tonight. (I was down to 10% left on my EHD.) Now I'll install the updated program to prevent it happening again.

THANKS!!!
pachinko likes this.
littlebrownjug is offline  
Sponsored Links
Advertisement
 
Reply HDTV Recorders

Thread Tools
Show Printable Version Show Printable Version
Email this Page Email this Page


Forum Jump: 

Posting Rules  
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are Off
Refbacks are Off