Prevue Guide Forums

Upon fidding with the curday.dat, it seems that the "0" in the 0.DREV.5 has some significance regarding the clock. In our case, it has always been set to "0", but when I set it "1" (or any other number), the time goes back one hour each time I reload the listings with SHIFT+D. I set it back to zero, and the time remained the same as before I pressed SHIFT+D. This even happens with a double digit number (I put 99 in and it did the same thing). Could this have anything to do with the DST setting in another file, for instance, whether or not it either adds or subtracts the hours? (I will likely test this later)

I am also inclined to believe that DREV is referring to a format revision for the listings, in our case format #5. I believe that this program is capable of translating five different data formats into listings. I am guessing there were four other past listing format revisions (perhaps from eras when there were less channel/program tags/flags, symbols, and special characters), and at one point it was something other than the format shown on the wiki (perhaps this is how they got the blue grid to show up in the black grid's format on that TN youtube video? The data had to have been sent that way and curday.dat configured as such). I think that eventually I am going to type the listings in a different way via trial and error in DREV.4, 3, etc. I noticed that when I tried it with my listings as is (and produced the "garbled" listings mentioned in an earlier post), it was actually the channel data but being pulled from an earlier entry in the channel data (like it pulls a tag/flag entry such as a 0 or a 1 rather than the program title, and doing this for each program and each channel creates a snowball effect). I think the further back the revision is, the less data was involved in the channel information (less tags, flags, etc). Changing the DREV causes ESQ to think there is too much information tied to each program (I am inclined to believe that the channel header remains the same format , since my entry for Channel 2 was correct except for programming, so it actually may just refer to program data format). An example I can give (just throwing this out there), what if each channel had 70 sets of data (or pieces separated by the null "00"s) on DREV.5, but on DREV.4 it had 65. This would make Channel 2's (or your first channel) title appear correct, since it is the first entry, but once it reaches a piece of data that was new in DREV.5 that wasn't in DREV.4, it thinks that piece of data goes to the following entry (it would be looking for DREV.4 format rather than DREV.5 format), and if there are 5 entries in DREV.5 that were not in DREV.4, from the point of that first difference, the listings will be off by an entire entry of data. But given in the example this would happen 5 times per channel, which means that all data would be further subsequently off further down the list (hence the snowball effect). The effect would likely be more drastic the further down the revision is.

I hope at least half of this ramble is in understandable language, but I can be certain this untested hypothesis creates a new curiousity for the curday.dat file. I may be wrong about some of this, but hopefully it helps someone else in the case they decide to test it further.

Some interesting findings here. At some point I would like to reverse engineer the listings handling code from ESQ, as I'm sure it contains all of the answers.

More progress on the DREV experiment. As we all know, DREV5 has five flags per program in the listings (Timeslot, flag1, flag2, flag3, 0). I removed the last "0" from each program on my experimental curday.dat, and with it set to DREV4, I got the first test channel to appear completely correct! However, any channel following the first must have a different way of displaying the channel header, because as seen here, it is off by only a couple spots (These two channels are exact copies of each other. The TS42 program on channel 1 is where it is supposed to be, but this same information is behind on channel 2, which is not displaying properly (the 42 seen in the first spot is actually the first flag with the time slot info... its not supposed to be seen as a program name). The masking flag is shown as the channel title for channel 2.

On DREV3, I cut the program tags down to 2 (timeslot, tag1) for channel 1 and down to 3 for channel 2. It seems that there is a variable number of tags. That 1 is from the 3rd program tag on program #11 on Channel 2. The CH2 TS12 is 6 spaces later in the file (so this program has SIX flags?), and five spaces later (like we know from DREV5) is the 14 from the 14th program's timeslot tag. I also did the program tags as 3 and 3, at which it seemed to still expect 5 flags per program on certain programs.

I may experiment more on this another time, but I have uploaded a couple images. If anyone wants a copy of any of my "test" curday.dat files, feel free to let me know. I think with more experimentation (and spare time) I might be able to figure out what other formats these listings will work in with the program. Let me know what you think.

Hmm, interesting stuff! I should crack open the code soon and see where exactly the DREV setting is originally set.

I'll leave that up to you. lol. I'm not very good at understanding code and disassembling a program. I don't mind testing theories, however (though I will continue to do so, as long as time permits). I would imagine that it would be neat to see what exactly the program expects from the listings in each of those settings. I wonder if there is any code in ESQ that is no longer used, but remanent of the A2-black or A2-blue beta. If only we could somehow "reprogram" ESQ to at least replicate the A2-black version, but as any of us could imagine, its probably beyond the scope of what we know at this point and is likely impossible