Exception after +/- 12hours of loop the same local file using set_position.

[JohnDoeMan]

Issue Report

Description

Error message:

org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.

I have python code looping a video between the position 27 seconds and 34 and when a input is detected it goes to second 0 and proceeds from there. So it's a infinite loop in the same file, i just manage the loop using set_position in order to mate a seamless loop between "2 videos" using the same vídeo.

One of the problems was the memory "infinite increase", i solved that by using /sbin/sysctl vm.drop_cache=3 to clean the cache on every iteration.

Problem reproduction

    player = OMXPlayer(VIDEOFILE, args=["--genlog","--adev",SOUND_OUTPUT,'--loop','--no-osd',"--aspect-mode",ASPECT_MODE,"--win", str(POSITION_X)+","+str(POSITION_Y)+","+str(WIDTH)+","+str(HEIGHT)])

    player.play()
    player.set_position(27)

    sensor = 0;
    while True:
        try:
            if (player != None):
                if (GPIO.input(PIN) == 1 and sensor == 0):
                    player.set_position(0)
                    sensor=1;
                    os.system('free -o -h')
                    os.system('vcgencmd measure_temp')
                    os.system('sudo /sbin/sysctl vm.drop_caches=3')
                else:
                    if(player.position()>34):
                        os.system('sudo /sbin/sysctl vm.drop_caches=3')
                        player.set_position(27)
                        sensor=0;
        except Exception as err:
            console.log("ERROR: PLAYING VIDEO: " + str(err))
            os.system("sudo pkill omxplayer")

Environment details

Distributor ID: Raspbian
Description:    Raspbian GNU/Linux 8.0 (jessie)
Release:        8.0
Codename:       jessie

dependency	version
python-dbus	1.2.0-2+b1
python	Python 2.7.9
omxplayer	6c90c75

[willprice]

Hi, thanks for the report.

Could you elaborate on what you mean by

One of the problems was the memory "infinite increase", i solved that by using /sbin/sysctl vm.drop_cache=3 to clean the cache on every iteration.

I'm not sure I understand what the issue is?

[willprice]

The docs for drop_cache

drop_caches

Writing to this will cause the kernel to drop clean caches, as well as reclaimable slab objects like dentries and inodes. Once dropped, their memory becomes free.

To free pagecache: echo 1 > /proc/sys/vm/drop_caches To free reclaimable slab objects (includes dentries and inodes): echo 2 > /proc/sys/vm/drop_caches To free slab objects and pagecache: echo 3 > /proc/sys/vm/drop_caches

This is a non-destructive operation and will not free any dirty objects. To increase the number of objects freed by this operation, the user may run `sync' prior to writing to /proc/sys/vm/drop_caches. This will minimize the number of dirty objects on the system and create more candidates to be dropped.

This file is not a means to control the growth of the various kernel caches (inodes, dentries, pagecache, etc...) These objects are automatically reclaimed by the kernel when memory is needed elsewhere on the system.

Use of this file can cause performance problems. Since it discards cached objects, it may cost a significant amount of I/O and CPU to recreate the dropped objects, especially if they were under heavy use. Because of this, use outside of a testing or debugging environment is not recommended.

You may see informational messages in your kernel log when this file is used:

cat (1234): drop_caches: 3

These are informational only. They do not mean that anything is wrong with your system. To disable them, echo 4 (bit 3) into drop_caches.

What are you hoping to achieve by calling this, and does it achieve it?

[willprice]

What commit or version of python-omxplayer-wrapperwere/are you using?

[JohnDoeMan]

Thanks for the reply, The os.system('sudo /sbin/sysctl vm.drop_caches=3') line is just to clear the cache otherwise it just keeps on climbing, still the problem occurs with or without that line.

The version is 0.1.0

I left it running this weekend with a 2 second loop, same thing, after 13 hours same error (without 'sudo /sbin/sysctl vm.drop_caches=3').

[willprice]

Hey @JohnDoeMan, why does it matter if the cache becomes full? If the references die then they can just be replaced by a live reference. Since you say the problem occurs regardless I'm going to ignore that line RE the issue.

How long is your video?

I see you're running free, what does -o do? My free doesn't have that flag. If you're printing out memory values what do they look like before the error occurs? Can you also get the CPU usage for a reasonable period (a few minutes) around the time the error occurs (before and after)

[willprice]

Closing. If anyone encounters this and can help me reproduce it, comment and I'll look into it.