Android:MediaPlayer isPlaying:0

时间:2016-09-16 10:32:52

标签: android android-mediaplayer surfaceview

此代码同步用于在线流式传输的surfaceview和mediaplayer

我的代码:

static SurfaceView           videoSurface;
static SurfaceHolder         videoHolder;
static MediaPlayer           mediaPlayer;

protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.page);
        videoSurface = (SurfaceView) findViewById(R.id.surfView);
        videoHolder = videoSurface.getHolder();
        videoHolder.addCallback((Callback) this);

        mediaPlayer = new MediaPlayer();

        new Thread(new Runnable() {

                @Override
                public void run() {
                    String link = "link.m3u8";

                    imgPlay.setOnClickListener(new OnClickListener() {

                    @Override
                    public void onClick(View arg0) {    
                        play(link);
                    }
                });
        }
    }).start();
}

public static void play(final String link) {
        new Thread(new Runnable() {

            @Override
            public void run() {
                try {
                    if (mediaPlayer == null) {
                        mediaPlayer = new MediaPlayer();
                        mediaPlayer.setAudioStreamType(AudioManager.STREAM_MUSIC);
                    }
                    mediaPlayer.setDisplay(videoHolder);
                    mediaPlayer.setDataSource(link);
                    mediaPlayer.setOnPreparedListener(new MediaPlayer.OnPreparedListener() {

                        public void onPrepared(MediaPlayer mp) {
                            mp.start();
                        }
                    });
                }
                catch (Exception e) {
                    e.printStackTrace();
                }
            }
            }).start();
    }

此代码可以工作但几秒后

如果在加载完成后点击imgPlay,则错误正在播放0

但是,如果我等待几秒钟,点击imgPlay播放后没有问题!

1 个答案:

答案 0 :(得分:1)

2016-09-17 06:39:15 [ERROR] akka.dispatch.TaskInvocation - Failed to acquire the lock in 60 seconds.
Possible reasons:
 - The lock was not released by the previous holder. If you use contexts API,
 for example map.queryContext(key), in a try-with-resources block.
 - This Chronicle Map (or Set) instance is persisted to disk, and the previous
 process (or one of parallel accessing processes) has crashed while holding
 this lock. In this case you should use ChronicleMapBuilder.recoverPersistedTo() procedure
 to access the Chronicle Map instance.
 - A concurrent thread or process, currently holding this lock, spends
 unexpectedly long time (more than 60 seconds) in
 the context (try-with-resource block) or one of overridden interceptor
 methods (or MapMethods, or MapEntryOperations, or MapRemoteOperations)
 while performing an ordinary Map operation or replication. You should either
 redesign your logic to spend less time in critical sections (recommended) or
 acquire this lock with tryLock(time, timeUnit) method call, with sufficient
 time specified.
 - Segment(s) in your Chronicle Map are very large, and iteration over them
 takes more than 60 seconds. In this case you should
 acquire this lock with tryLock(time, timeUnit) method call, with longer
 timeout specified.
 - This is a dead lock. If you perform multi-key queries, ensure you acquire
 segment locks in the order (ascending by segmentIndex()), you can find
 an example here: https://github.com/OpenHFT/Chronicle-Map#multi-key-queries

java.lang.RuntimeException: Failed to acquire the lock in 60 seconds.
Possible reasons:
 - The lock was not released by the previous holder. If you use contexts API,
 for example map.queryContext(key), in a try-with-resources block.
 - This Chronicle Map (or Set) instance is persisted to disk, and the previous
 process (or one of parallel accessing processes) has crashed while holding
 this lock. In this case you should use ChronicleMapBuilder.recoverPersistedTo() procedure
 to access the Chronicle Map instance.
 - A concurrent thread or process, currently holding this lock, spends
 unexpectedly long time (more than 60 seconds) in
 the context (try-with-resource block) or one of overridden interceptor
 methods (or MapMethods, or MapEntryOperations, or MapRemoteOperations)
 while performing an ordinary Map operation or replication. You should either
 redesign your logic to spend less time in critical sections (recommended) or
 acquire this lock with tryLock(time, timeUnit) method call, with sufficient
 time specified.
 - Segment(s) in your Chronicle Map are very large, and iteration over them
 takes more than 60 seconds. In this case you should
 acquire this lock with tryLock(time, timeUnit) method call, with longer
 timeout specified.
 - This is a dead lock. If you perform multi-key queries, ensure you acquire
 segment locks in the order (ascending by segmentIndex()), you can find
 an example here: https://github.com/OpenHFT/Chronicle-Map#multi-key-queries

    at net.openhft.chronicle.hash.impl.BigSegmentHeader.deadLock(BigSegmentHeader.java:59)
    at net.openhft.chronicle.hash.impl.BigSegmentHeader.updateLock(BigSegmentHeader.java:231)
    at net.openhft.chronicle.map.impl.CompiledMapIterationContext$UpdateLock.lock(CompiledMapIterationContext.java:768)
    at net.openhft.chronicle.map.impl.CompiledMapIterationContext.forEachSegmentEntryWhile(CompiledMapIterationContext.java:3810)
    at net.openhft.chronicle.map.impl.CompiledMapIterationContext.forEachSegmentEntry(CompiledMapIterationContext.java:3816)
    at net.openhft.chronicle.map.ChronicleMapIterator.fillEntryBuffer(ChronicleMapIterator.java:61)
    at net.openhft.chronicle.map.ChronicleMapIterator.hasNext(ChronicleMapIterator.java:77)
    at java.lang.Iterable.forEach(Iterable.java:74)