Using Smart EPG on Australian Model TMS

[FireBird]

1) Maybe there is some misunderstanding. A repeat is not bound to the constraints (only to the channel if "Same channel" is selected) because if the Toppy can't record the main timer, it will try to get hold of the programme regardless of the setting of the main timer.

2) If it is still the case after restarting SE, you probably have more than one .lng on your Toppy. Remember that SE needs to be restarted after changes to a .lng. V5.1 was the last non-beta. Go to the TAPtoDate options and enable the display of beta versions.

[keith_leitch]

[quote="keith_leitch"]1) When I restrict the search for a show to a certain day or days, the search still creates timers for ALL days that the show is on. For example, I have one set for only SAT SUN, but the show records when it airs on Thursday. This was working properly in the older version.

2) The "No" option for the "Allow Combine" feature shows...

3) The guide (option 3, I think) still shows sequential numbers for each channel rather than the LCN.[/quote]


Thanks. Your advice about the .lng file has solved problem 2. "Allow Combine" is now displaying options. Is there any way to set every search by default to allow "Same Series" to be combined (so I do not have to set it every time)?

I am attaching the first two photos to illustrate problem 3; you can see that the station named ELEVEN should (quite logically) have an LCN of 11, but the "guide" view still numbers it sequentially as "10." This is very minor, but I thought you might like to know about it.

With problem 1: I understand what you are saying, but what I am saying is that it now records the second and third airing even if it already recorded the first. The third photo might help to explain what I mean. On Thursday, Star Trek: Deep Space Nine will record three episodes. Exactly the same three episodes are on Saturday. With version 5.1, the Saturday airing would not record a second time, but now it does.

I will try it on just "Series" for awhile, to see what happens.

[gazza]

I've been observing problem 1 for some time now. It seems to occur with series timers which are also combination timers. If the settings are changed so that no combining is allowed, the repeats will no longer be recorded. I prefer to have the multiple episodes in one recording though, so I've just put up with this behaviour...

[keith_leitch]

You are probably right, because I only started using combination timers at around the same time that 5.3 was released.

[FireBird]

To summarize: a repeat timer, which is part of a combination timer, is not removed after the main show has been successfully recorded?

[gazza]

[quote="FireBird"]To summarize: a repeat timer, which is part of a combination timer, is not removed after the main show has been successfully recorded?[/quote]

Yes, that seems to be the case. I've just had a look at SE's FileDB and the previous shows which were part of a combination timer aren't listed, so this may be the reason why the repeats are being recorded.

[keith_leitch]

[quote="FireBird"]To summarize: a repeat timer, which is part of a combination timer, is not removed after the main show has been successfully recorded?[/quote]

That is right. I am not sure whether it also applies to non-repeating combination timers, but I am still experimenting. I will get back to you with results after the work-week is done.

[FireBird]

I'm a bit puzzled because V5.3 had fixed exactly what you're describing.

Bugfix: combi timers haven't been rebuilt if a recording has been marked as OK during the recording. This means that the same series has been recorded twice if it was part of a combi timer

Are the unwanted timers really marked as series timers (circling arrows in the red dot)?

[keith_leitch]

[quote="FireBird"]I'm a bit puzzled because V5.3 had fixed exactly what you're describing.

Are the unwanted timers really marked as series timers (circling arrows in the red dot)?[/quote]

Yes, they definitely are. The photo I sent is an example. However, I have since discovered that searches marked "Allow Combine" do not necessarily record unwanted repeats; it seems to be only after they actually combine that they do so.

In other words, I marked "Allow Combine" on a series that was only running a single episode. It recorded, and the repeat did not record, just as desired. However, when I mark "Allow Combine" on a series that runs two or more episodes in a row, those same episodes will record again later in the week.

I will continue to experiment.

Can I also make the suggestion for a future release that combination timers have the episode descriptions appended together?

[keith_leitch]

I was thinking more about this: If the TAP is looking for matches in a recordings database, then perhaps it is the combination name that is causing the problem. For example, "Star Trek" does not match "Star Trek (2 Episodes)." This would explain why everything is fine when there is no second episode aired.

[FireBird]

Keith, could you please take the newest .tgz file from "/ProgramFiles/Settings/SmartEPG_TMS/Backup" and send it by email (you can find my email address under my user profile). If you have Auto Backup (item 34) active, a backup has been created every day after the EPG scan. If not, please create one by using "Create backup" item 32.

[FireBird]

Thanks for the logs, Keith. What I’ve gathered is that after the recording has been deemed ok, the members of the combi timers – including the repeats - have been blocked.

Code: Alles auswählen

2013-11-14 20:23:05 new file  736 000000000000142d '/mnt/hd/DataFiles/Star Trek: Deep Space Nine (3 Episodes)_2013-11-14 20-33.mpg'
2013-11-14 20:23:05 rec signature = 00fada41

2013-11-14 23:36:05 RecLenOK flag of 'Star Trek: Deep Space Nine (3 Episodes)_2013-11-14 20-33.mpg' set to OK
2013-11-14 23:36:05 TimerDB: blocking repeat '00 'Star Trek: Deep Space Nine' (2013-11-14 20:33/62') (R=b879, V=bd37)'
2013-11-14 23:36:05 TimerDB: blocking repeat '02 'Star Trek: Deep Space Nine' (2013-11-14 21:35/60') (R=a560, V=bd37)'
2013-11-14 23:36:05 TimerDB: blocking repeat '03 'Star Trek: Deep Space Nine' (2013-11-14 22:36/59') (R=43e0, V=bd37)'
2013-11-14 23:36:05 TimerDB: blocking repeat '13 'Star Trek: Deep Space Nine' (2013-11-16 12:00/60') (R=05ad, V=5f23)'
2013-11-14 23:36:05 TimerDB: blocking repeat '15 'Star Trek: Deep Space Nine' (2013-11-16 13:00/60') (R=de2a, V=5f23)'
2013-11-14 23:36:05 TimerDB: blocking repeat '16 'Star Trek: Deep Space Nine' (2013-11-16 14:00/60') (R=941f, V=5f23)'
2013-11-14 23:36:05 TimerDB: blocking repeat '18 'Star Trek: Deep Space Nine' (2013-11-17 02:15/55') (R=b7c5, V=04e1)'
2013-11-14 23:36:05 TimerDB: blocking repeat '20 'Star Trek: Deep Space Nine' (2013-11-17 03:10/55') (R=02e7, V=04e1)'
2013-11-14 23:36:05 TimerDB: blocking repeat '21 'Star Trek: Deep Space Nine' (2013-11-17 04:05/55') (R=b360, V=04e1)'

What is missing here is a “deleting combi timer” message and that tells me that the combi timer itself survived and triggered the unwanted recordings. I’ve identified a piece of code, which might be responsible for that bug and hopefully it is fixed with the next release, which will appear the next few days.

[keith_leitch]

Good job. I'm sorry I haven't checked back for a few days.

In case it helps you to trace the problem, there is another small bug involving episodes of a program that are scheduled back-to-back. It is hardly even an inconvenience, but I mention it in case it helps with debugging.

Basically, special characters are not always filtered in a combi timer; in other words, the filename is still "Star Trek: Deep Space Nine," instead of "Star Trek Deep Space Nine." This is not only a problem with combi-timers, but any time multiple episodes air one after another. In other words, if I record three episodes of "Star Trek: Deep Space Nine" in a row, then the first file is correctly called "Star Trek Deep Space Nine," but the second and third are still "Star Trek: Deep Space Nine."

[keith_leitch]

I have been unable to use TAPTODATE for awhile, now, to update my TAPs. It seems that it is not connecting to the network; every attempt to download anything fails, and I cannot see recent versions of TAPS listed (e.g. the lastest I see for SmartEPG is v5.1). I have successfully done file transfers using FTP, so I assume my connection is OK. Does anyone have any ideas?

[Twilight]

have a look in the network configuration. do you use two dns server?
try to use: 8.8.8.8 and 8.8.4.4

twilight

[keith_leitch]

I will try, but I thought I would have to use the DNS servers that are configured for my LAN.

[Maliboy]

Sometimes, the DNS Lookup of the Topfield is to Short. Google hast very Fast DNS Servers but I don't like them too (Google now enough about me) but for a check you can use it.

Use you a local DNS Server in your Router or an External from your Provider?

[keith_leitch]

I think I am using one of each--local and external--but I will have to check later. Thanks for the advice; it will give me something to try.

[Maliboy]

Then use both local (can be the Same). As I know, linux use Round Robin for DNS. So the TOPFIELD will always aks onetime the local and onetime the external. And if the external is to slow, there will be an error.

[keith_leitch]

I know it has been a long time since I've followed this up; that is how busy work has been.

I am afraid that I cannot make any progress with this. I have tried the DNS servers recommended, my two local DNS servers and two global DNS servers. No matter what I do, TAPtodate will not communicate with its server. What is very strange is that it was working fine until sometime before I made my original post.