EPG data growing without bounds

  Olaf Titz wrote:
> There is a problem in VDR where the "X" lines in the epg.data file get
> duplicated at every restart of VDR (at least?), leading to an ever
> growing file and eventual out of memory errors. The following patch
> for 1.3.25 (also applies to .27) seems to fix this. It assumes that
> the "Components" in the EPG data structures are supposed to be unique,
> so it makes them unique (wrt. all fields - if this assumption is wrong
> the tComponent::equals() function should be adapted).
> 
> Olaf
> 
> --- epg.h.orig	Sat May 28 13:32:36 2005
> +++ epg.h	Tue Jul  5 20:33:30 2005
> @@ -28,7 +28,8 @@
>    char *description;
>    cString ToString(void);
>    bool FromString(const char *s);
> -  };
> +  bool equals(uchar ostream, uchar otype, const char *olanguage, const char *odescription);
> +};
> 
>  class cComponents {
>  private:
> @@ -39,7 +40,7 @@
>    cComponents(void);
>    ~cComponents(void);
>    int NumComponents(void) const { return numComponents; }
> -  void SetComponent(int Index, const char *s);
> +  void SetComponent(const char *s);
>    void SetComponent(int Index, uchar Stream, uchar Type, const char *Language, const char *Description);
>    tComponent *Component(int Index) const { return (Index < numComponents) ? &components[Index] : NULL; }
>    };
> --- epg.c.orig	Sun May 29 12:19:48 2005
> +++ epg.c	Tue Jul  5 20:33:29 2005
> @@ -38,6 +38,12 @@
>    return n >= 3;
>  }
> 
> +bool tComponent::equals(uchar ostream, uchar otype, const char *olanguage, const char *odescription)
> +{
> +    return stream == ostream && type == otype && !strcmp(language, olanguage)
> +        && ( (description == NULL && odescription == NULL) || !strcmp(description, odescription) );
> +}
> +
>  // --- cComponents -----------------------------------------------------------
> 
>  cComponents::cComponents(void)
> @@ -63,8 +69,13 @@
>       }
>  }
> 
> -void cComponents::SetComponent(int Index, const char *s)
> +void cComponents::SetComponent(const char *s)
>  {
> +  for (int i = 0; i < numComponents; i++) {
> +    if (!strcmp(s, *components[i].ToString()))
> +      return;
> +  }
> +  int Index = numComponents;
>    Realloc(Index);
>    components[Index].FromString(s);
>  }
> @@ -270,7 +281,7 @@
>                break;
>      case 'X': if (!components)
>                   components = new cComponents;
> -              components->SetComponent(components->NumComponents(), t);
> +              components->SetComponent(t);
>                break;
>      case 'V': SetVps(atoi(t));
>                break;
> --- eit.c.orig	Sat May 28 13:35:55 2005
> +++ eit.c	Tue Jul  5 20:11:34 2005
> @@ -198,8 +198,17 @@
>                   if (1 <= Stream && Stream <= 2 && Type != 0) {
>                      if (!Components)
>                         Components = new cComponents;
> +                    int index = 0;
>                      char buffer[256];
> -                    Components->SetComponent(Components->NumComponents(), cd->getStreamContent(), cd->getComponentType(), I18nNormalizeLanguageCode(cd->languageCode), cd->description.getText(buffer, sizeof(buffer)));
> +                    cd->description.getText(buffer, sizeof(buffer));
> +                    const char *lang = I18nNormalizeLanguageCode(cd->languageCode);
> +                    while (index < Components->NumComponents()) {
> +                        tComponent *c = Components->Component(index);
> +                        if (c->equals(Stream, Type, lang, buffer))
> +                            break;
> +                        index++;
> +                    }
> +                    Components->SetComponent(index, Stream, Type, lang, buffer);
>                      }
>                   }
>                   break;
> 
> === end of patch ===

Since the code in VDR/eit.c always sets a completely new (and thus consistent)
set of components, the only way this can happen is through SVDRP's PUTE command
(or while reading epg.data). In order to fix this I believe this should suffice:



That way, whenever an event definition is encountered, its components
are reset and the new set of components is defined as given.

Existing epg.data files that already contain duplicate component
entries won't be fixed by this, so either delete them or just wait
until those entries get washed out over time.

Klaus
  

On Sat, 2005-07-30 at 16:48 +0200, Klaus Schmidinger wrote:

> Since the code in VDR/eit.c always sets a completely new (and thus consistent)
> set of components, the only way this can happen is through SVDRP's PUTE command
> (or while reading epg.data). In order to fix this I believe this should suffice:

This patch + manual removal of epg.data seems to have cured the
descriptions-are-off-by-one problems I mentioned earlier in this thread.
Thanks!